[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