[9,8u60] RFR (S): 8074551: GWT can be marked non-compilable due to deopt count pollution

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jun 10 17:04:08 UTC 2015

Looks good to me.

Vladimir K.

On 6/10/15 5:34 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8074551/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8074551
> JDK-8063137 added profiling machinery for GWT combinator.
> In order to avoid trap count pollution, trap counts are simply ignored
> during JIT compilation for methods w/ injected profile.
> Unfortunately, it not enough to completely eliminate trap count
> pollution problem. As the regression test case demonstrates, VM marks
> heavily shared method as non-compilable when too many traps happen
> there. It causes severe performance regression since the method is
> neither compiled nor inlineable anymore.
> With the fix, VM doesn't update trap counts in methods with injected
> profile when trap reason is either intrinsic or unreached. These are 2
> kinds of uncommon traps VM issues based on injected profile.
> I experimented with completely ignoring trap count updates for methods
> with injected profile, but it causes noticeable regression on a couple
> of Octane subbenchmarks [2].
> I reverted injected profile detection logic and reintroduced an explicit
> marker for methods which inject profile (@InjectedProfile). All GWTs are
> marked with it during bytecode translation.
> Testing: jdk/test/java/lang/invoke, hotspot/test/compiler/jsr292,
> nashorn, octane (no perf regression)
> Best regards,
> Vladimir Ivanov
> [1] https://bugs.openjdk.java.net/browse/JDK-8063137
> [2] FTR Richards (340ms->370us) & Regexp(100ms->135ms)

More information about the hotspot-compiler-dev mailing list