Bug ID: JDK-8074551 GWT can be marked non-compilable due to deopt count pollution

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 8u60,9

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2015-03-06
Updated: 2015-09-29
Resolved: 2015-06-11

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 8	JDK 9
8u60Fixed	9 b71Fixed

If shared GWT causes too many recompilations, VM marks it as non-compilable.
It's caused by deopt count pollution. GWTs are heavily shared and deopt counts shouldn't be taken into account for GWT.

ILW = HL?M = P3 I = H = huge performance regression once recompilation cutoff is reached L = L? = rare (haven't seen on Octane) W = M = turn off recompilation cutoff logic (-XX:PerBytecodeRecompilationCutoff=-1 -XX:PerMethodRecompilationCutoff=-1)
11-06-2015
ILW=Suboptimal perf behaviour, always, Turnoff recompilation cutoff (-XX:PerBytecodeRecompilationCutoff=-1 -XX:PerMethodRecompilationCutoff=-1)=MHM=P3
13-03-2015
Current mechanism of avoiding profile pollution (ciMethod::has_injected_counts() in Compile::too_many_traps/too_many_recompiles) doesn't cover recompilation counts. Consider reverting to @DontProfile marker for heavily shared methods w/ injected profile. Probably, keeping such methods w/o MDO is enough.
06-03-2015
Workaround: -XX:PerBytecodeRecompilationCutoff=-1 -XX:PerMethodRecompilationCutoff=-1
06-03-2015

Duplicate :	JDK-8075273 - MHs.GWT methods can be marked as non-compilable due to deopt count profile pollution
Relates :	JDK-8063137 - Never taken branches should be pruned when GWT LambdaForms are shared