United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7013538 Java memory leak with escape analysis
JDK-7013538 : Java memory leak with escape analysis

Details
Type:
Bug
Submit Date:
2011-01-20
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
windows_2003,generic,windows
Sub-Component:
compiler
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs20,6u24
Fixed Versions:
hs21 (b03)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3763ca6579b7
                                     
2011-02-08
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.
                                     
2011-02-08



Hardware and Software, Engineered to Work Together