JDK-7017240 : C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2011-02-04
  • Updated: 2018-01-05
  • Resolved: 2011-03-08
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 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
Relates :  
Description
nsk/regression/b4675027 crashes due to OOM during method compilation.

It crashes when it tries to load com.sun.tools.hat.internal.oql.OQLEngine and all its dependencies. 
The problematic method is:
	sun.org.mozilla.javascript.internal.Interpreter::interpretLoop(7102 bytes)

Only 32-bit Server VM on Windows in comp mode is affected when G1 is used. I wasn't able to reproduce the crash in other modes.

Simplified test case:
public class Test {
    public static void main(String args[]) throws Exception {
        Class initClass = Class.forName("com.sun.tools.hat.internal.oql.OQLEngine");
    }
}

The test fails from at least b120 to b125 (hs20-b03 to hs20-b06). Starting b126 it stops failing, though VM version is the same (hs20-b06). I suppose some JDK changes hid the bug. 

How to reproduce:
   - login to vmsqe-xeon-05.russia
   - java -server -Xcomp -XX:+UseG1GC -cp .;%JDK%/lib/tools.jar Test
   or
   - cd cd K:/execution/results/JDK7/PROMOTION/VM/7/b122/G1/vm/windows-i586/server/comp/windows-i586_vm__server_comp_nsk.regression.testlist/ResultDir/b4675027
   - bash rerun.sh

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/194c9fdee631
08-02-2011

PUBLIC COMMENTS C2 adds additional code for G1 barriers so ideal graph may become larger then with other collectors. Also the compiled method itself is huge: 7102 bytes. Main part of the problem is memory resources usage during escape analysis and it will be resolved with 7013538 fix. But I also noticed that PhaseIdealLoop::build_and_optimize() allocates next arrays without freeing resources on exit (there is no ResourceMark): _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size ); Add ResourceMark to build_and_optimize().
08-02-2011

EVALUATION C2 adds additional code for G1 barriers so ideal graph may become larger then with other collectors. Also the compiled method iteself is huge: 7102 bytes. Main part of the problem is memory resources usage during escape analysis and it will be resolved with 7013538 fix. But I also noticed that PhaseIdealLoop::build_and_optimize() allocates next arrays without freeing resources on exit (there is no ResourceMark): _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size );
04-02-2011