Re: Smalltalk and tiered compile data
Thanks Rémi Off to give it a try mark From: Rémi Forax To: mlvm-dev@openjdk.java.net Date: 02/09/2012 11:08 AM Subject:Re: Smalltalk and tiered compile data Sent by:mlvm-dev-boun...@openjdk.java.net On 02/08/2012 10:47 PM, Mark Roos wrote: > Hi Rémi Hi Mark, > > I think I am starting to get it. > > My normal fallback creates a GWT and does a getTarget + setTarget on > the root callsite to put this GWT at the > head of the chain. I assume that this use of setTarget is as expected > and causes no problems. I think I > found this technique in some of your early code. yes ! > > For the switchPoint approach I would set the first (root) target to a > switchPoint which invokes a new callsite > which then takes the normal fallback. This keeps the switchPoint at > the head with the GWT chain now > growing from the second callsite. > > The invalidate path has a method handle which will create a new > switchPoint with fallbacks and place it > in the root callsite replacing the now dead switchPoint. This > setTarget will occur on the next invocation > of the root callSite after the invalidation. > > This state is similar to the first after a bootstrap. yes ! > > So I am going to do a lot of setTargets. One for each method cache > miss and again for every call site which > is invalidated plus any lookups it needs to do. > > Given that every setTarget involves a safe point this sounds like it > could get expensive. Should I be > concerned? No :) setTarget() doesn't implies automatically a safepoint. There is a safepoint if you do a setTarget() on a Callsites which have been used to generate a compiled code. > > thanks > > mark > cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On 02/08/2012 10:47 PM, Mark Roos wrote: > Hi Rémi Hi Mark, > > I think I am starting to get it. > > My normal fallback creates a GWT and does a getTarget + setTarget on > the root callsite to put this GWT at the > head of the chain. I assume that this use of setTarget is as expected > and causes no problems. I think I > found this technique in some of your early code. yes ! > > For the switchPoint approach I would set the first (root) target to a > switchPoint which invokes a new callsite > which then takes the normal fallback. This keeps the switchPoint at > the head with the GWT chain now > growing from the second callsite. > > The invalidate path has a method handle which will create a new > switchPoint with fallbacks and place it > in the root callsite replacing the now dead switchPoint. This > setTarget will occur on the next invocation > of the root callSite after the invalidation. > > This state is similar to the first after a bootstrap. yes ! > > So I am going to do a lot of setTargets. One for each method cache > miss and again for every call site which > is invalidated plus any lookups it needs to do. > > Given that every setTarget involves a safe point this sounds like it > could get expensive. Should I be > concerned? No :) setTarget() doesn't implies automatically a safepoint. There is a safepoint if you do a setTarget() on a Callsites which have been used to generate a compiled code. > > thanks > > mark > cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
Hi Rémi I think I am starting to get it. My normal fallback creates a GWT and does a getTarget + setTarget on the root callsite to put this GWT at the head of the chain. I assume that this use of setTarget is as expected and causes no problems. I think I found this technique in some of your early code. For the switchPoint approach I would set the first (root) target to a switchPoint which invokes a new callsite which then takes the normal fallback. This keeps the switchPoint at the head with the GWT chain now growing from the second callsite. The invalidate path has a method handle which will create a new switchPoint with fallbacks and place it in the root callsite replacing the now dead switchPoint. This setTarget will occur on the next invocation of the root callSite after the invalidation. This state is similar to the first after a bootstrap. So I am going to do a lot of setTargets. One for each method cache miss and again for every call site which is invalidated plus any lookups it needs to do. Given that every setTarget involves a safe point this sounds like it could get expensive. Should I be concerned? thanks mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On 02/08/2012 02:55 AM, Mark Roos wrote: > Hi Rémi > > Just a clarification on the switchpoint usage to invalidate sites. > > The switch path would still do a setTarget correct? No, SwitchPoint.invalidateAll() doesn't call setTarget(). > So I am still sending lots of > setTargets just based on switch point state? No. The idea is that you introduce a guard created from the SwitchPoint at the beginning of your target. You create the guard with a target (your old target) and a fallback which in this case is the fallback that you install when you call setTarget. When you call invalidateAll with all your SwitchPoints (you can create one by signature if you want) then the VM ask all other threads to go to a safe point. For all callsite targets that have been JITed, the code is marked as dead and the next call to invokedynamic on that callsite will go through the target method handle tree instead of calling the JITed code. When the VM will call the guard of the invalidated SwitchPoint instead of calling the target, it will calll the fallback method of the guard. All will be done at one safepoint. > > It also seems that if the switch point is in series with the target > that the callsite will not > invalidate until its next use. technically, it's the guard of the switch point which is in serie but yes, JITed code willl be dropped later (when no callsite will be able to call it) and if the code is not JITed, the SwitchPoint is just turn off so nothing will be done until the callsite is called again. > Seems like this could spread the invalidations out over time > giving hotspot even more to do. No, because the VM will be able to do the cleanup without using a safepoint and the cleanup phase is not something heavy. > > Or am I not clear on how to do this? > > thanks > mark cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
Hi Rémi Just a clarification on the switchpoint usage to invalidate sites. The switch path would still do a setTarget correct? So I am still sending lots of setTargets just based on switch point state? It also seems that if the switch point is in series with the target that the callsite will not invalidate until its next use. Seems like this could spread the invalidations out over time giving hotspot even more to do. Or am I not clear on how to do this? thanks mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
>From Rémi Mark, you should use a SwitchPoint I was thinking of that. I'll move it up on the list of things to try. My current approach gives me the option to filter the callsites and only invalidate the ones for a given signature. This would only matter if I have issues with hotspot as I would prefer to invalidate them all. This keeps the GWT depth under control. by sweeping them all out every so often. thanks mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On 02/07/2012 08:28 PM, Mark Roos wrote: > Christian asked: > > What exactly do you mean by "invalidate call sites before the > benchmark"? > Are you using MutableCallSites and call setTarget on them? > > Exactly. I am using setTarget to set each call site to its initial > fallback method. This should drop the > GWT lookup chain forcing each call site to rebuild the chain. The > method handles for the code still exist but > the GWTs that reference them are gone. This is my current way to > force the call sites to get new versions > of the method code. > > thanks Mark, you should use a SwitchPoint instead of calling a lot of setTarget() because each setTarget() may require all threads of the VM to go to a safepoint so you may create a 'safepoint storm' (as coined by Dan Heidinga). > > mark Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
Christian asked: What exactly do you mean by "invalidate call sites before the benchmark"? Are you using MutableCallSites and call setTarget on them? Exactly. I am using setTarget to set each call site to its initial fallback method. This should drop the GWT lookup chain forcing each call site to rebuild the chain. The method handles for the code still exist but the GWTs that reference them are gone. This is my current way to force the call sites to get new versions of the method code. thanks mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On Feb 3, 2012, at 1:25 AM, Mark Roos wrote: > So I ran some tests using a simple benchmark using the jdk8-b23 from the > Openjdk google code. > > Without tiered compile I get: ( times in nanoseconds ) > 52101000 > 53973000 > 20932000 > > with tiered on > 493788000 > 521448000 > 513287000 > 34293 > 15048000 > > But if I invalidate all call sites before the benchmark with tiered I see: > > 449127000 > 288584000 > 80717000 > 36255000 > > and without tiered > 4921 > 744625000 > 27179000 > 26377000 > 24514000 > > in all cases more runs after show no changes for 30 runs. > > So tiered starts very very very slow but ends better. Both seem to have a > hard time if call sites have their > targets reset. > > any thoughts on how I might get the best always? Especially for callsite > resets. What exactly do you mean by "invalidate call sites before the benchmark"? Are you using MutableCallSites and call setTarget on them? > > And why would the startup be 10x slower for tiered? Good question. The run times are long enough (around 0.5s) that a C2 compile should happen in the first runs. But maybe I'm wrong. Igor, do you have an idea? -- Chris > > By the way the data for jdk7u4 is similar but its best times are slower. > > regards > mark___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Smalltalk and tiered compile data
So I ran some tests using a simple benchmark using the jdk8-b23 from the Openjdk google code. Without tiered compile I get: ( times in nanoseconds ) 52101000 53973000 20932000 with tiered on 493788000 521448000 513287000 34293 15048000 But if I invalidate all call sites before the benchmark with tiered I see: 449127000 288584000 80717000 36255000 and without tiered 4921 744625000 27179000 26377000 24514000 in all cases more runs after show no changes for 30 runs. So tiered starts very very very slow but ends better. Both seem to have a hard time if call sites have their targets reset. any thoughts on how I might get the best always? Especially for callsite resets. And why would the startup be 10x slower for tiered? By the way the data for jdk7u4 is similar but its best times are slower. regards mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
