[9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Oct 28 19:04:47 UTC 2014


John, thanks for the feedback!
See my answers inline.

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8059877/webrev.02/

> The algorithm looks fine, as long as the count is small.  (Otherwise we
> might want to spend effort recompiling the DontInline LF.
Yes, the intention is to have it small - about the same as 
COMPILE_THRESHOLD. I experimented with recompiling all affected 
nmethods, but it seriously slows down warmup once recompilation limit is 
hit.

> Call it CountingWrapper, since that's what it does.  (Count down vs.
> count up doesn't matter much.)
> Then you can call the states "counting" and "not counting".  The
> pre-action is present only in the counting state.
> The aspect of inlining or blocking is then focused down to a detail of
> the LF flavor.
> You call DelegatingMethodHandle.makeReinvokerForm in three places, two
> of which are identical calls.  I suggest refactoring so as to call it in
> two places.
I decided to go the following route: I factored CountingWrapper logic, 
but instead of caching lambda forms for counting & non-counting cases, I 
cache lambda form producers (MethodHandle -> LambdaForm). It allows to 
delay LF instantiation for non-counting case and create new lambda forms 
for DelegatingMethodHandle::asTypeUncached in CoutingWrapper.

My observations show that about half of the wrappers stay in counting 
state, so I decided it makes sense to delay LF instantiation.

> (Nit: As a matter of style, the default value of a boolean flag should
> be usual one, in typical cases.  By that reasoning, LF.forceInline
> should be LF.dontInline; the objection to this is that it is anti-style
> to have a negative word in a boolean name.)
If you don't mind, I decided to leave forceInline flag name as is.

> You could create and cache *both* reinvoker forms when the MH wrapper is
> created, so that the non-counting, inline-enabled LF is created more
> eagerly during warmup.  It might make for a smoother warmup.  (Maybe.
>   Maybe not.)
Good point! I decided to precompile non-counting LF before setting it.

Best regards,
Vladimir Ivanov


More information about the mlvm-dev mailing list