|
Quick Lists
|
|
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
|
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
|
|
|
 |