JDK-8046809 : vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-13
  • Updated: 2024-11-22
  • Resolved: 2014-10-24
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 9
9 b40Fixed
Related Reports
Relates :  
JDK-8244278 - Excessive code cache flushes and sweeps
Relates :  
JDK-8062250 - [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal
Relates :  
JDK-8062735 - CodeCacheSweeperThread missing from SA
Relates :  
JDK-8064669 - compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts
Relates :  
JDK-8344548 - Incorrect StartAggressiveSweepingAt doc for segmented code cache
Relates :  
JDK-8060196 - 'CodeHeap is full' warning suggests to increase wrong code heap size
Relates :  
JDK-8079646 - [mlvm] Avoid CodeCache overflows in general MLVM tests
Sub Tasks
JDK-8169580 :  
Add documentation for JDK-8046809 to Tools Reference Guide - Resolved
Description
The test timedout because compilation was disabled after CodeCache become full.

vm/mlvm/meth/stress/compiler/deoptimize

CodeCache: size=49152Kb used=48639Kb max_used=48646Kb free=513Kb
 bounds [0xffffffff77000000, 0xffffffff7a000000, 0xffffffff7a000000]
 total_blobs=27339 nmethods=18605 adapters=8692
 compilation: disabled (not enough contiguous free space left)

Why CodeCache flushing did not help?
Comments
verified by nightly testing
26-07-2017
No release note required because this change is already documented in the Tools Reference Guide.
20-03-2017
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/956bdea3c7e0 User: lana Date: 2014-11-17 19:26:14 +0000
17-11-2014
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/956bdea3c7e0 User: anoll Date: 2014-10-24 14:06:12 +0000
24-10-2014
Nightly bug -> P1
08-10-2014
Same ILW, but this is a nightly bug -> HLH=P2
07-10-2014
Adapted changes for segmented code cache: http://cr.openjdk.java.net/~anoll/8046809/webrev.01/
03-10-2014
Bug occurs also with the segmented code cache.
03-10-2014
The problem is that we generate an artificially large number of adapters. CodeCacheMinimumFreeSpace in not large enough to hold all adapters, if the code cache gets full. Furthermore, the JVM is in a state where no safepoint is requested. As a result, stack scanning of active methods does not happen and consequently, nmethods cannot be flushed from the code cache. Two changes help mitigating the problem 1) Introduce a new VM operation that forces stack scanning of active methods 2) Use a dedicated sweeper thread that processes the whole code cache at once (remove NmethodSweepFraction) The proposed patch can be found here: http://cr.openjdk.java.net/~anoll/8046809/webrev.00/ I'll wait with reviewing until the segmented code cache is integrated.
29-08-2014
When the code cache becomes full, we have 5441K allocated for adapters.
20-08-2014
ILW=Failed test (No more code cache flushing), this scenario only, none=MLH=P4
16-06-2014
We're running out of space because we don't ever flush adapters: # ERROR: java.lang.VirtualMachineError: out of space in CodeCache for adapters # ERROR: at sun.misc.Unsafe.defineAnonymousClass(Native Method) # ERROR: at java.lang.invoke.InvokerBytecodeGenerator.loadAndInitializeInvokerClass(InvokerBytecodeGenerator.java:254) # ERROR: at java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:246) # ERROR: at java.lang.invoke.InvokerBytecodeGenerator.generateLambdaFormInterpreterEntryPoint(InvokerBytecodeGenerator.java:1021) # ERROR: at java.lang.invoke.LambdaForm.getPreparedForm(LambdaForm.java:655) # ERROR: at java.lang.invoke.LambdaForm.prepare(LambdaForm.java:566) # ERROR: at java.lang.invoke.MethodHandle.<init>(MethodHandle.java:463) # ERROR: at java.lang.invoke.SimpleMethodHandle.<init>(SimpleMethodHandle.java:37) # ERROR: at java.lang.invoke.SimpleMethodHandle.permuteArguments(SimpleMethodHandle.java:60) # ERROR: at java.lang.invoke.MethodHandles.permuteArguments(MethodHandles.java:2076) # ERROR: at vm.mlvm.meth.share.transform.v2.MHPermuteTF.computeInboundMH(MHPermuteTF.java:48) # ERROR: at vm.mlvm.meth.share.transform.v2.MHBasicUnaryTF.computeInboundMH(MHBasicUnaryTF.java:32) # ERROR: at vm.mlvm.meth.share.transform.v2.MHPrimitiveTF.computeInboundCall(MHPrimitiveTF.java:15) # ERROR: at vm.mlvm.meth.share.transform.v2.MHMacroTF.addTransformation(MHMacroTF.java:47) # ERROR: at vm.mlvm.meth.share.MHTransformationGen.createSequence(MHTransformationGen.java:388) # ERROR: at vm.mlvm.meth.share.MHTransformationGen.createAndCallSequence(MHTransformationGen.java:433) # ERROR: at vm.mlvm.meth.stress.compiler.deoptimize.Test.runThread(Test.java:89) # ERROR: at vm.mlvm.share.MultiThreadedTest$2.run(MultiThreadedTest.java:49) # ERROR: at java.lang.Thread.run(Thread.java:745)
13-06-2014
flags: -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=100
13-06-2014
RULE vm/mlvm/meth/stress/compiler/deoptimize Timeout none
13-06-2014