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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Jun 11 10:46:42 UTC 2015

Thanks, Vladimir.

Best regards, Vladimir Ivanov

On 6/10/15 8:04 PM, Vladimir Kozlov wrote:

Looks good to me.

Thanks, 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