Bug ID: JDK-7013538 Java memory leak with escape analysis

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 6	JDK 7	Other
6u27Fixed	7Fixed	hs20.2Fixed

Application run with -XX:+DoEscapeAnalysis grows up to machine memory and crashes after 46 hours. Examining core file shows that there are many instances of java.util.zip.* classes. It appears that java.util.zip.ZipFile and/or java.util.zip.ZipFile$ZipFileInputStream are never closed and occupy Java heap and native memory. Running same application without -XX:+DoEscapeAnalysis does not reproduce this problem.

Object Histogram:

num       #instances    #bytes  Class description
--------------------------------------------------------------------------
1:              2273889 724202304       byte[]
2:              220925  227457368       char[]
3:              755258  36252384        java.util.zip.ZipFile$1
4:              755258  36252384        java.util.zip.ZipFile$ZipFileInputStream
5:              773194  18556656        java.util.HashMap$Entry

PUBLIC COMMENTS First, it is not leak. I instrumented VM around method compilation call to see if there are allocations which are not freed. There are none. I used mechanism similar to NoHandleMark to catch direct calls to os::malloc() (NoMallocMark). I found only one case (see below) but it frees memory almost immediately. The rest (major part) of allocations happened on thread Resource area and Compile arena which return used Chunks to ChunkPool after each compilation. But ChunkPool could become very large with EA. It is cleaned each 5 sec by VM task but there could be situations when 2 compilers threads request a lot of memory during 5 sec period causing out of memory problems. So the problem is compilation with EA consumes C heap a lot more than without it. Collected allocation statistics during one hour of the test run (dacapo is running eclipse several times) shows that used C Heap size with EA is around 500Mb when without EA it is only 150Mb (not all of it is used, it could be fragmented because of the problem 2 below). Also numbers of calls to os::malloc rises from 2.5 millions to 10.5 M. The main cause of native memory consumption is allocation of GrowableArray and VectorSet in next very hot EA method: void ConnectionGraph::PointsTo(VectorSet &ptset, Node * n) { VectorSet visited(Thread::current()->resource_area()); GrowableArray<uint> worklist; And the cause of a lot calls to os::malloc() is VectorSetI iterator which is used only by EA but it is used a lot, it could also cause C heap fragmentation: SetI_ *VectorSet::iterate(uint &elem) const { VSetI_ *foo = (new(ResourceObj::C_HEAP) VSetI_(this)); elem = foo->next(); return foo; } The first problem is fixed by reusing structures in PointsTo(). I also added Reset() method to VectorSet to zero data array instead of freeing it. The second problem is fixed by adding new simple VectorSetI iterator (old iterator was removed) which is not based on SetI and doesn't need VSetI_. I also fixed compile time statistics for EA since it is now part of Optimizer.

08-02-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3763ca6579b7

08-02-2011

Duplicate :	JDK-7042582 - REGRESSION:Out of Memory Error (allocation.cpp:317) - Java 6u25
Relates :	JDK-7017240 - C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1
Relates :	JDK-7040769 - REGRESSION:jvm crash with intellij on 6u25
Relates :	JDK-7105611 - Set::print() is broken