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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
