What about notifyGenericMethodType? Should that be notifyGeneralMethodType?
There are others like ToGeneric and
test/java/lang/invoke/InvokeGenericTest.java. Is the intent just to clean up
the public API language and worry about any internals later?
Looks good.
tom
On May 11, 2011, at 9:02
I've reviewed this as well as I could and it all looks reasonable.
tom
On May 11, 2011, at 9:08 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/6939861/webrev.jdk.06/
>
> This is the JDK code which works on top of ricochet frames.
>
> These frames were put into the JVM last week, also
Looks ok.
tom
On May 17, 2011, at 4:45 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7032850/webrev.00/
>
> 7032850: MethodHandle.invokeGeneric throws unspecified RuntimeException if
> parameterized method is called
> Summary: Implement invocation corner cases, including correct typ
MethodTypeForm.java:
-if (c != null) {
+if (c == void.class)
+c = null; // a Void parameter was unwrapped to void; ignore
+if (c != null && c != void.class) {
You don't need to both tests against void.class do you?
Otherwise it looks good.
to
Looks ok.
tom
On May 17, 2011, at 5:07 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/6983728/webrev.00/
>
> 6983728: JSR 292 remove argument count limitations
> Summary: Remove workarounds and limitations from before 6939861.
> Reviewed-by: ?
>
> Remove test exclusions from MethodHa
Is it the inlining policy? I played a little with this and the current default
policy is still not as good as the big tweaks to MaxInlineSize and
InlineSmallCode.
tom
On May 20, 2011, at 1:21 PM, Charles Oliver Nutter wrote:
> Meh, false alarm. This is just the default empty Object[] assigned
If there were to be a recursive inline in there, where would it occur? I can't
tell from the names where in that inline tree where the recursive call occurs.
tom
On May 23, 2011, at 2:26 PM, Charles Oliver Nutter wrote:
> fib_ruby LogCompilation inlining graph, showing that fib_ruby is not
> i
sun.invoke.util.ValueConversions::identity (2 bytes)
>>
>> This seems to only be the test logic; the actual fib invocation
>> doesn't appear to show up in the inlining graph at all. Am I right?
>>
>> I see two of these in the LogCompilation output and nothing else
On May 23, 2011, at 3:27 PM, Charles Oliver Nutter wrote:
> On Mon, May 23, 2011 at 5:20 PM, Tom Rodriguez
> wrote:
>>
>> On May 23, 2011, at 2:50 PM, Charles Oliver Nutter wrote:
>>> I also do not see any indication *why* nothing inlines past this
>>> poin
On May 23, 2011, at 5:13 PM, Charles Oliver Nutter wrote:
> On Mon, May 23, 2011 at 6:17 PM, Rémi Forax wrote:
>> On 05/24/2011 12:44 AM, Tom Rodriguez wrote:
>>> I haven't been following 292 that closely but it used to be a piece of code
>>> that did precisely
2011-05-24 06.11, John Rose wrote:
>> On May 23, 2011, at 3:44 PM, Tom Rodriguez wrote:
>>
>>>> I'd *love* for intermediate static Java snippits like this to
>>>> inline straight through, even if invokeExact would be megamorphic
>>>> under norma
I've got the bimorphic method handle inline working. I was doing something
stupid at the beginning which is why it wasn't as easy as I expected to be and
then I encountered a stupid API which wasted a little more time. I was able to
leverage the existing invokedynamic call site cache code gen
On May 25, 2011, at 9:39 PM, Charles Oliver Nutter wrote:
> On Wed, May 25, 2011 at 5:12 PM, Tom Rodriguez
> wrote:
>> I've got the bimorphic method handle inline working. I was doing something
>> stupid at the beginning which is why it wasn't as easy as I e
Overall it seems ok. A few minor oddities:
MethodHandle.java
variable arity is sometimes hyphenated. It seems more correct without but be
consistent.
AdapterMethodHandle.java:
The new value srcSlot appears unused.
Should this just go away:
-if (argCount <= 2) return false; // mus
isValid looks fine.
tom
On May 26, 2011, at 1:31 AM, John Rose wrote:
> On May 25, 2011, at 11:58 PM, Tom Rodriguez wrote:
>
>> Overall it seems ok. A few minor oddities:
>>
>> MethodHandle.java
>>
>> variable arity is sometimes hyphenated. It s
There's something deeply bizarro about that assembly. It looks like x64
assembly decoded by the 32 assembler. I think your hsdis wasn't built right.
tom
On May 26, 2011, at 2:13 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez
> wrote:
&
I'll see what I can do on my mac.
tom
On May 26, 2011, at 3:45 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:16 PM, John Rose wrote:
>> I posted the bsd/amd64 libdis when I was desperate for something that would
>> at least link and partially decode instructions. But that hsdis
I'm seeing slow perf as well but I think it might be a jruby/292 mismatch
problem:
Exception :
java.lang.invoke.MethodHandles.convertArguments(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodT\
ype;)Ljava/lang/invoke/MethodHandle; (0xefdd4b18 )
thrown
[/net/smite.us.oracle.com/export/ws/
Looks good.
tom
On Jun 3, 2011, at 12:48 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7051206
>
> This is a changed method name (and inverted sense), replacing
> SwitchPoint.isValid. Here's the updated javadoc:
>
> hasBeenInvalidated
> public boolean hasBeenInvalidated()
> Determ
On Jun 3, 2011, at 12:12 AM, Charles Oliver Nutter wrote:
> I did make another small discovery: the + calls never inline
> completely. They eventually are a virtual invocation of
> RubyFixnum.op_plus, and in both old and new builds they're calls in
> the asm.
That's not what I see when I run it.
On Jun 2, 2011, at 7:37 PM, John Rose wrote:
> Thanks; I'll look at your dump later tonight.
>
> If the problem is friction from interface casts, we can probably remove them.
> It's hard to figure out how they are getting in, though. It happens when
> IRubyObject interconverts with Object.
I get the following message when I try to run it:
InvokeDynamicSupport.java:468:in `invocationFallback':
java.lang.invoke.WrongMethodTypeException:
(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime
On Jun 15, 2011, at 12:27 PM, Charles Oliver Nutter wrote:
> On Wed, Jun 15, 2011 at 10:32 AM, Tom Rodriguez
> wrote:
>> I get the following message when I try to run it:
>>
>> InvokeDynamicSupport.java:468:in `invocationFallback':
>> java.lang.invoke.WrongM
On Jun 15, 2011, at 11:47 AM, Christian Thalinger wrote:
> On Jun 15, 2011, at 8:08 PM, Charles Oliver Nutter wrote:
>> FWIW, I only get the crash on my MLVM build if I pass these flags to JVM:
>>
>> -XX:MaxInlineSize=150 -XX:InlineSmallCode=3000
>>
>> See README and use jruby.jar from this rep
`internalRun'
from Main.java:164:in `run'
from Main.java:148:in `run'
from Main.java:128:in `main'
Does that help? I'm testing the WMT fix and we can probably generate an mlvm
patch for it so you can try it out. I'll keep you posted.
tom
On
On Jun 17, 2011, at 3:06 AM, Rémi Forax wrote:
> On 06/17/2011 11:50 AM, Christian Thalinger wrote:
>
> [...]
>
>>> I wonder if I haven't introduce a bug in my logic,
>>> there is a the boxing/unboxing of the return value of the test that
>>> should not occur.
>>> Question, does EA is also disa
On Jun 17, 2011, at 5:00 PM, John Rose wrote:
> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>
>>>
>>> Sorry, I was thinking recording which branch of the GWT is taken and
>>> storing them in the GWT.
>>> Two GWTs should not share the same metad
On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
> On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
>> On Jun 17, 2011, at 5:00 PM, John Rose wrote:
>>
>>> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>>
>>>>> Sorry, I was thinking recording wh
Could you provide more detail on this? I just ran the all these against b146
and they all pass cleanly for a large collection of configs. One thing you
have to watch out for is an issue on 64 bit where the code cache fills up
because some of the stress tests use a lot of signatures. Run with
_klass();
Note the !cpool.is_null() part. Hopefully John will update the patch when he
gets a chance.
tom
On Jun 22, 2011, at 12:04 PM, Stephen Bannasch wrote:
> At 10:30 AM -0700 6/22/11, Tom Rodriguez wrote:
>> Could you provide more detail on this? I just ran the all these against
&
I think you are seeing 6990212. Breakpoints should work fine but single
stepping requires some machinery in the interpreter to make sure that we never
jump into compiled code but the method handle path has doesn't have that code.
Method entry events use the same machinery. If you want to try
On Jun 29, 2011, at 7:41 PM, Mark Roos wrote:
> John stated
> Like performance tuning, debugger support is something we will be
> addressing after FCS.
>
> No problem. I did notice that creating arrays on the target side ( to hold
> objects found by
> instances) is very slow ( abou
On Jul 6, 2011, at 4:18 AM, Christian Thalinger wrote:
> On Jul 5, 2011, at 6:39 PM, Charles Oliver Nutter wrote:
>> I'm not in position at this exact moment to report perf issues, but
>> Rémi's list would be a good start. I'll return to JRuby benchmarks and
>> start looking for specific bottlene
On Jul 27, 2011, at 2:50 AM, Charles Oliver Nutter wrote:
> I'm getting back into invokedynamic stuff (in between
> conferencing...whew!). Perf reports are coming soon, but in the
> interim
>
> I was playing with implementing "loops" using the trick Ola showed me
> of binding a call site in
Since hotspot is delivered into multiple releases we've officially kind of
separated from the release specific trees except at points where we deliver a
snapshot into them. The live development repos for hotspot are under
http://hg.openjdk.java.net/hsx, so
http://hg.openjdk.java.net/hsx/hotspo
dependencies.cpp:
in check_call_site_target_value, the changes == NULL case should be checking
that the call site hasn't changed. It should probably look more like this:
klassOop Dependencies::check_call_site_target_value(klassOop ctxk, oop
call_site, CallSiteDepChange* changes) {
assert(cal
On Aug 8, 2011, at 11:52 AM, Vladimir Kozlov wrote:
> Christian Thalinger wrote:
>> On Aug 8, 2011, at 4:55 PM, Vladimir Kozlov wrote:
>>
>>> Christian,
>>>
>>> Should we put "skip bytecode quickening" code under flag to do this only
>>> when invoke dynamic is enabled? Or put_code is zero only
>> I guess my concern is that the original (long) version may or may not
>> inline, but obviously doesn't degrade as badly. Why does the degraded
>> performance of the long form suffer so much? Ruby is a very terse
>> language, often resulting in methods that represent a lot of code. I'm
>> using i
On Aug 9, 2011, at 4:33 AM, Christian Thalinger wrote:
>
> On Aug 8, 2011, at 8:49 PM, Tom Rodriguez wrote:
>
>> dependencies.cpp:
>>
>> in check_call_site_target_value, the changes == NULL case should be checking
>> that the call site hasn't changed.
>>
>
> I wonder if this patch is not too much.
> If a big method is called through an invokedynamic + method handle
> then it will be inlined.
That's not how it works. The methods called by the adapter will still have to
pass normal inlining checks before being inlined so at worst you just en
> Well, it's the good old:
>
> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size >
> DesiredMethodLimit
>
> This seems to be the last recursive call that doesn't get inlined. Setting
> MaxRecursiveInlineLevel=0 makes it go faster. I finally filed (a separate
> bug to keep
On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
> On Fri, Aug 12, 2011 at 1:18 PM, Tom Rodriguez
> wrote:
>> I wonder if we need to be slightly more selective than this. Most method
>> handle chains are relatively small and we shouldn't be penalized for tha
On Aug 15, 2011, at 3:19 PM, Charles Oliver Nutter wrote:
> On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez
> wrote:
>>
>> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>>> Well, let me play devil's advocate here: why not just discount MH
>>
On Aug 9, 2011, at 12:02 PM, Charles Oliver Nutter wrote:
> On Tue, Aug 9, 2011 at 2:31 PM, Charles Oliver Nutter
> wrote:
>> On Tue, Aug 9, 2011 at 4:30 AM, Christian Thalinger
>> wrote:
>>> Hmm. I remember you were saying this is some old Ultra 20. The only box I
>>> could find which is si
>>>
>>
>> I'm open to suggestions on this one.
>>
>> It seems to me that the bsd-port repo. is slowing down prior to absorption
>> into the mainline.
>>
>> In this case, maybe the rational thing is to reparent to a faster-moving
>> repo.
>>
>> In particular, I think we should reparent to fro
I made one:
import java.lang.invoke.*;
import static java.lang.invoke.MethodHandles.*;
import static java.lang.invoke.MethodType.*;
public class RM implements Runnable {
public static void main(String... args) throws Throwable {
new Thread(new RM()).start();
}
public static R
I didn't expect you to still be working and I was pretty sure how to reproduce
it...
tom
On Aug 24, 2011, at 12:41 PM, Christian Thalinger wrote:
>
> On Aug 24, 2011, at 8:44 PM, Tom Rodriguez wrote:
>
>> I made one:
>>
>> import java
On Aug 31, 2011, at 12:23 PM, Mark Roos wrote:
> Very interesting, I see that I need a hint for the class/method name. ( it
> is the source file name but that doesn't print here)
>
> getNIl/true and false are currently a probe into a hash map but should be a
> static var. I can
> see that
On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote:
> On 13.09.2011 00:59, John Rose wrote:
>> This exposes the question of liveness: JVMs routinely nullify
>> non-live variables, but what if the only remaining use is the
>> getLocalArray intrinsic? Shouldn't it count as a weak reference?
Looks good.
tom
On Sep 19, 2011, at 3:09 PM, John Rose wrote:
> 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init
> http://cr.openjdk.java.net/~jrose/7077803/webrev.00
>
> Remove access checking and access narrowing logic from
> MethodHandles.unreflectX calls, if is
On Sep 27, 2011, at 9:37 PM, Mark Roos wrote:
> Just wondering if anyone is working on this. Particularly breakpoints and
> stepping
That was fixed a while back, at least as far our tests say. It was 6990212.
Are you still seeing problems? The only JVMTI feature still not working is
clas
On Sep 28, 2011, at 3:31 PM, Mark Roos wrote:
> From Tom
> That was fixed a while back, at least as far our tests say. It was 6990212.
> Are you still seeing problems? The only JVMTI feature still not working is
> class redefinition and that will be fixed for 7u4.
>
> Would that have been
On Oct 4, 2011, at 4:47 PM, Charles Oliver Nutter wrote:
> Hey all...I'm updating and expanding my talk on C2 and will be posting
> some questions. Hopefully there's someone out there who can answer
> them :)
Fire away.
>
> First up... given this output from PrintCompilation, what do the "!"
>
On Oct 4, 2011, at 5:12 PM, Matt Fowles wrote:
> Tom~
>
> On Tue, Oct 4, 2011 at 8:04 PM, Tom Rodriguez
> wrote:
> > First up... given this output from PrintCompilation, what do the "!"
> > and "n" and "%" mean?
>
> ! means the
On Oct 13, 2011, at 9:01 PM, Charles Oliver Nutter wrote:
> Ok Hotspot guys, I have a challenge for the JIT. I want to basically do this:
>
> try {
> ...
> } catch (Exception e) {
> if (!(e instanceof SomeException)) throw e;
> ... handle e as SomeException
> }
>
> instead of explicitly addi
That seems to be a bug. hprof needs to be updated for 292. I filed 7101843
for this.
tom
On Oct 13, 2011, at 8:53 PM, Charles Oliver Nutter wrote:
> FWIW, option 2 (hprof) seems like a no-show on u2b08:
>
> headius@headius-vbox-ubuntu:~/projects/redblack$
> JAVA_HOME=~/jdk1.7.0_02/ ../jruby/
Netbeans has a profiler built in, though I don't know how well it works and I
don't know if it's been updated for 292. The Sun Studio Analyzer does a very
good job capturing profiles without a lot of overhead though it only runs on
Solaris and Linux. The very latest version supports 292 but I
On Dec 1, 2011, at 1:34 AM, Charles Oliver Nutter wrote:
> My recent explorations into Stephen B's perf degradation on JRuby have
> led me to an unfortunate conclusion: something SwitchPoint-related is
> responsible for the remaining slowdown.
>
> I had bugs I fixed, like the awful PIC-causes-re
58 matches
Mail list logo
