On Mar 2, 2015, at 12:00 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote: > > Charlie, I found the root cause. > > So, the problem is never-taken branches indeed. > The way how branch profiling for GWT (JDK-8063137 [1]) is performed doesn't > work well. > > I hoped that profile collection and injection actions can be merged ( > MHI.profileBoolean) into single action, but it's not the case. It means that > counter isn't updated when deopt event happens. For rarely taken branches, it > means that the method can be recompiled between 2 rare events and the > application will experience a series of deopt/recompilation events. > > I have to split MHI.propfileBoolean in 2 parts: MHI.attachProfile and > MHI.updateProfile. > > MHI.attachProfile will be used as MHI.profileBoolean, but w/o updating > counts. Actual profiling will happen in MHI.updateProfile which will be > called on both branches. So, when deopt happens the very first thing it does > is bump the count. > > The other problem is that deopt counts pollution can force GWT method to be > marked as non-compilable. It seems I should go back to explicit hint for JIT > to avoid method profiling (e.g. @DontProfile). > > I'm working on the fix for both problems and will file a bug shortly.
Thanks for chasing that down, Vladimir. We have been down this road before with profiling: If you don't update the profile on the uncommon path, then the system can make decisions based on inaccurate profile data. That's a main reason there is so much profile updating in deoptimization.cpp. So let's make hindsight work for us: Is there a way (either with or without the split you suggest) to more firmly couple the update to the query? Separating into two operations might be the cleanest way to go, but I think it's safer to keep both halves together, as long as the slow path can do the right stuff. Suggestion: Instead of have the intrinsic expand to nothing, have it expand to an uncommon trap (on the slow path), with the uncommon trap doing the profile update operation (as currently coded). — John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
