On Apr 28, 2011, at 3:19 PM, Charles Oliver Nutter wrote: > On Thu, Apr 28, 2011 at 5:16 AM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: >> I took a look at it. I used 64-bit x86 since the code is a bit smaller than >> with 32-bit. >> >> The code is almost identical but three things popped into my eye (the output >> is from PrintOptoAssembly): >> >> 1. The obvious one: the method handle call site guard: >> >> 1a4 B32: # B160 B33 <- B31 B149 B123 Freq: 0.499969 >> 1a4 movq R10, byte[int:>=0]<ciObject ident=770 PERM address=0xe99088> >> * # ptr >> 1ae movq R10, [R10 + #1576 (32-bit)] # ptr >> 1b5 movq R11, [R10 + #32 (8-bit)] # ptr >> 1b9 movq R8, java/lang/invoke/AdapterMethodHandle:exact * # ptr >> 1c3 cmpq R11, R8 # ptr >> 1c6 jne,u B160 P=0.000000 C=-1.000000 > > I saw in your other email that eliminating this puts indy on par with > dynopt, which is spectacular news. Can you elaborate on how that would > be possible to do "correctly" (as in not via a hack)? Would it be a > lighter-weight check and deopt of some kind (in Hotspot), or is it > something I'd need to rig up on my code?
This would be what we referred to in the past as pull-vs-push notification. I don't have details about that yet but maybe John has already thought this through and has an implementation idea (or even details). Not sure when get around to implement that. -- Christian _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
