Customers are seeing a 3-6MB memory leak in their application when running
the hotspot jvm in NT service pack 5. All their system are running without the JIT. The leak is not present if the -classic option is used. It doesn't appear when running the 1.1.7 JDK either, in which they previously ran.

Customer is using the following 3rd party software:

- a database
- some Borland classes
- some KL group classes (mainly GUIs)


Customers are using native code for hardware display.
Their applictaion has a lot of repainting of AWT/Swing components to do
after every few seconds. If the application is left for some time (2-8 hours
depending on the available memory), with no activity besides the component repaints, the machine will run out of memory. Customer has moved most of their user interface to swing API, and can not run their application on 1.2.2 due to the changes in swing.

The leak is also reproduced when the application runs a continous loop
of image paints within a component. If this loop is left running with no other
activity in the application the memory will leak at approximately 6MB/min.


For one system (the image loop) the memory is 1-2 GB
For the other (memory runs out over time) the memory is 500MB-1GB


customers normally run their scripts with -ms equal to -mx and
for 500MB systems -ms = -mx = 100m
for 1GB systems -ms = -mx = 200m
for 2GMB systems -ms = -mx = 600m

They always got
java.lang.OutOfMemoryError in a reproducible test steps.


log result of Prism run with Optimizer on 3/22/2001

Exception occurred during event dispatching:
java.lang.OutOfMemoryError:
at sun.awt.image.BufferedImageGraphics2D.lock(BufferedImageGraphics2D.java:1372)
at sun.java2d.loops.LockableRaster.<init>(LockableRaster.java:93)
at sun.java2d.loops.RasterOutputManager$RenderImageCachedState.getDstLR(RasterOutputManager.java:361)
at sun.java2d.loops.RasterOutputManager.renderImage(RasterOutputManager.java:472)
at sun.java2d.SunGraphics2D.renderingPipeImage(SunGraphics2D.java:2067)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:1761)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:1649)
at sun.awt.image.BufferedImageGraphics2D.drawImage(BufferedImageGraphics2D.java:362)
at com.ge.med.ptk.laf.PtkIconCache$TiledIcon.paintIcon(PtkIconCache.java:259)
at com.ge.med.ptk.laf.PtkButtonUI.paint(PtkButtonUI.java:202)
at javax.swing.plaf.ComponentUI.update(ComponentUI.java:39)
at javax.swing.JComponent.paintComponent(JComponent.java:398)
at javax.swing.JComponent.paint(JComponent.java:739)
at javax.swing.JComponent.paintChildren(JComponent.java:523)
at javax.swing.JComponent.paint(JComponent.java:748)
at javax.swing.JComponent.paintWithBuffer(JComponent.java:4393)
at javax.swing.JComponent._paintImmediately(JComponent.java:4336)
at javax.swing.JComponent.paintImmediately(JComponent.java:4187)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:370)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:205)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:154)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:317)
at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:103)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:84)
.................


customer has tried the latest 1.3.1
(Release candidate ) with the following configuration and they still saw the major memory leak
nothing seems to change with the Xss flag.

On WinNT4, 2G RAM, jvm=1.3.1-rc2 (hotspot):

-ms=100m -mx=600m -Xss128k [~3M/min leak]
-ms=100m -mx=600m -Xss256k [~2M/min leak]
-ms=100m -mx=600m [~2-3M/min leak]

-ms=200m -mx=600m -Xss128k [~3M/min leak]
-ms=200m -mx=600m -Xss256k [~2M/min leak]
-ms=200m -mx=600m [~2-3M/min leak]

-ms=600m -mx=600m -Xss128k [~4M/min leak]
-ms=600m -mx=600m -Xss256k [~4M/min leak]
-ms=600m -mx=600m [~4-6M/min leak]

On Win2000, 2G RAM, jvm=1.3.1-rc2 (hotspot):

-ms=100m -mx=600m -Xss128k [~1M/min leak]
-ms=100m -mx=600m -Xss256k [~1M/min leak]
-ms=100m -mx=600m [~1M/min leak]

-ms=600m -mx=600m -Xss128k [~1M/min leak]
-ms=600m -mx=600m -Xss256k [~1M/min leak]
-ms=600m -mx=600m [~1M/min leak]


Customer has determined that the leak is in native heap in using task manager in NT. No leak in java heap by using Optimixeit.


Customer can't generate a test case due to the complexity of their application. However, customer is extremely willing to work with Sun, as well as send us their engineers and equipment to help us solve this problem, at their expense!