Mailing-List: contact batik-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xmlgraphics.apache.org
From: bugzilla@apache.org
To: batik-dev@xmlgraphics.apache.org
Subject: DO NOT REPLY [Bug 46863] DeflaterOutputStream not closed, causes
 OutOfMemoryError
In-Reply-To: <bug-46863-30099@https.issues.apache.org/bugzilla/>
References: <bug-46863-30099@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20090421150929.82758234C046@brutus.apache.org>
Date: Tue, 21 Apr 2009 08:09:29 -0700 (PDT)

https://issues.apache.org/bugzilla/show_bug.cgi?id=46863


--- Comment #5 from liamsb@ca.ibm.com  2009-04-21 08:09:25 PST ---
Hi,

I have run some more tests. Here are the results:

With the gc() calls, the test case ran out of java heap space after running for
almost four hours:
Exception in thread "main" java.lang.OutOfMemoryError
    at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:52)
    at
java.awt.image.SinglePixelPackedSampleModel.createDataBuffer(SinglePixelPackedSampleModel.java:231)
    at
sun.awt.image.IntegerInterleavedRaster.<init>(IntegerInterleavedRaster.java)
    at
sun.awt.image.IntegerInterleavedRaster.createCompatibleWritableRaster(IntegerInterleavedRaster.java:527)
    at
java.awt.image.AffineTransformOp.createCompatibleDestImage(AffineTransformOp.java:459)
    at java.awt.image.AffineTransformOp.filter(AffineTransformOp.java:220)
    at org.apache.batik.svggen.SVGGraphics2D.drawImage(SVGGraphics2D.java:995)
    at A.main(A.java:21)

Since we are drawing images repeatedly to the SVGGraphics2D, it's not
surprising that it eventually runs out of java heap space.

Running the test case (without the gc() calls) in a profiler shows frequent
garbage collection and still crashes within 10 minutes. (I saw between 2-50
garbage collections per 10 second period, and 350+ total collections.)  Thus,
it seems unlikely that the OOME is caused by the garbage collector not having a
chance to run.

My understanding is that the jvm will not throw an OutOfMemoryError on an
allocation without first running a garbage collection to attempt to free enough
space for the allocation.

The Sun defect (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4797189)
explains that the garbage collector is not aware of the native memory
associated with the Deflater instances, and therefore does not anticipate that
freeing these objects will provide the needed native heap space.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org