InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Vladimir Ivanov]

Never-taken GWT branches (on per-MH instance basis) are aggressively 
pruned during JIT-compilation.

So, in the worst case, a MH chain containing 6 GWT can experience 6 
recompilations.

I don't know what Java version you use, but there were a number of bugs 
fixed in HotSpot, which manifested as methods marked as non-compilable 
due to profile pollution (e.g., JDK-8074551 [1]). I suggest to monitor 
JIT compiler activity as well.

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8074551

On 5/31/16 10:41 PM, Mark Roos wrote:
> I have been implementing a Smalltalk on the JVM (Rtalk)  which has gone
> quite well.  But recently
> I was told that one of our key benchmarks had suffered a large slowdown,
>  from a few hundred
> mS to seconds.  And strangely it gets slower the more its executed until
> we reset all of the call sites.
>
> Looking closer I found at least one reproducible cause which leads me to
> think that there is some
> issue with how I do PICs and how Hotspot tries to inline them.
>
> We have a common case where we reset an array of objects by copying one
> instance var to another.
> The Smalltalk class of each value can be one of several so there is some
> level of polymorphism at
> each site.  Interesting for several of these arrays the reset time was
> 200uS or so but for one it was
> 1000 mS.  The only difference was that in the fast ones the Smalltalk
> class types were bunched while
> in the slow case they were distributed.  I found that by setting all of
> the Smalltalk classes to the same
> type the time dropped to a few hundred uS. Leading me to think my PIC
> was the problem.
>
> The problem Smalltalk code looks like this:
>    idleValue isNil
>         ifFalse:[finalValue := idleValue deepCopy]
>         ifTrue:[finalValue := default].
>
> There are two invoke dynamic sites, isNil and deepCopy.  Removing
> deepCopy has little effect but
> removing the isNil test saves most of the time.  Interesting isNil is a
> very small method ( returns a
> constant of true or false ) so my thought is that it would be logically
> inlined.  While deepCopy is large.
>
> It looks like, from some fine timing, that each time the Smalltalk class
> changes there is a large amount
> of time added to the call.  Which I would expect if there was a deopt
> whenever a different GWT triggered.
> There are 6 GWTs in this chain ( idleValue can be one of six Smalltalk
> classes).
>
> Any ideas on how I can avoid this?
>
> Notes:
> Each of my Smalltalk objects is an instance of a single Java class.  The
> Smalltalk class is determined
> by a compare on one of its instance vars.  So looking at the Java class
> at a callsite it would always
> be a constant.
>
> My call site chain looks like
>         a mutable site whose target is a fixed set of methodHandles
> terminated by another mutable site
>         whose target is the chain of GWTs.
>
> thanks
> mark
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>