On 04/29/2011 01:09 PM, Christian Thalinger wrote: > On Apr 28, 2011, at 3:19 PM, Charles Oliver Nutter wrote: >> On Thu, Apr 28, 2011 at 5:16 AM, Christian Thalinger >> <[email protected]> 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.
The API for push notification is MutableCallSite.syncAll/SwitchPoint.invalidateAll and is not currently implemented in the RI. The idea is that instead of using a guard to check if there is a meta model change, the target of a callsite has no guard for that but the runtime track all these callsites. By example for a + callsite in JRuby, you only install a guard that check if the current object is a Fixnum using a getClass() identity check. If someone somewhere open the Fixnum class to change something, the runtime will change all callsites that use Fixnum to set their targets to fallbacks that use a slow path and then call MutableCallSite.syncAll on all these callsites. syncAll ensures that only the new targets (the fallbacks) are visible for the whole program. Instead of using syncAll you can use SwitchPoint.invalidateAll which allow you to create a special guard on a condition like is my meta model change or not. This guard is not a real one because instead of doing the check each time when it calls, it does nothing but when the SwitchPoint is invalidated, the guard is replaced by its fallback doing a kind of deoptimization. Currently in the RI, SwitchPoint checks a volatile field instead of doing the optimization/deoptimization. I'm not far from having this working in the backport (I'm just stuck with a memory model issue). So currently, the push API is here but there is no support from hotspot. I guess we should to kill any people that will be between John and a keyboard until he implements MutableCallSite.syncAll. > -- Christian Rémi _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
