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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Jun 10 12:34:15 UTC 2015


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