Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4454091
Votes 5
Synopsis memory leak in native heap with JDK 1.3 Hotspot
Category hotspot:garbage_collector
Reported Against 1.3
Release Fixed
State 11-Closed, Not a Defect, bug
Priority: 1-Very High
Related Bugs 4395735
Submit Date 03-MAY-2001
Description
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  customer  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!
Work Around
Use -classic option.  However, this is not an option for cusomer.
Evaluation
Ok I read the description and have some ideas about it.
What I need is a call from the customer who intimately familiar with the problem  and the CODE of the application. Email is not practical since each next question depends on the answer to previous one.

  xxxxx@xxxxx   2001-05-23


The customer has reported that this is not a bug.

  xxxxx@xxxxx   2001-06-11
Comments
  
  Include a link with my name & email   

Submitted On 28-FEB-2002
abhardwaj
Why is it not a bug ? It is a bug and I am also getting the 
same problem with this version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
When I use the classic mode I don't see this problem. 
Same problem exists with JRE 1.3 plug-in also. I tried JRE 
1.4 plugin also, there also I have the same problem. 



PLEASE NOTE: JDK6 is formerly known as Project Mustang