-
Bug
-
Resolution: Duplicate
-
P4
-
6u10
-
x86
-
linux_ubuntu
FULL PRODUCT VERSION :
JDK6+
A DESCRIPTION OF THE PROBLEM :
Following a discussion I had on the 2d-dev mailing list on 25. april 2009
(see http://mail.openjdk.java.net/pipermail/2d-dev/2009-April/000769.html )
I am uploading this simple sample to show how simple it is to cause StrikeCache to consume huge amounts of memory.
Running the sample with java -server -Xmx1024 causes an OOM of native heap after some time.
The problem is StrikeCache uses SoftReferences, which are very seldom cleared by the hotspot-server.
Probably a better idea would be some kind of "soft limit", however I don't have an implementation.
In the xrender pipeline this is solved using a hard limit.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
StrikeCache should limit the amount of native memory used.
ACTUAL -
The JVM OOMs as soon as the process hits the 2GB barrier, on a 32bit system - and consumes extremly huge amounts of memory on 64-bit systems.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.image.*;
import java.util.*;
public class FontOOMTest {
public static void main(String[] args) {
Image bImg =new BufferedImage(1024, 1024, BufferedImage.TYPE_INT_RGB);
Graphics2D g = (Graphics2D) bImg.getGraphics();
Random rand = new Random();
while(true) {
g.setFont(new Font("Dialog", Font.PLAIN, rand.nextInt(100)));
g.rotate(rand.nextDouble()%100);
g.drawString("qwertzuiopasdfghjklyxcvbnnnnmQWERTZUIOPASDFGHJKKKLLYXCVBNNM12345678990", 512, 512);
}
}
}
---------- END SOURCE ----------
JDK6+
A DESCRIPTION OF THE PROBLEM :
Following a discussion I had on the 2d-dev mailing list on 25. april 2009
(see http://mail.openjdk.java.net/pipermail/2d-dev/2009-April/000769.html )
I am uploading this simple sample to show how simple it is to cause StrikeCache to consume huge amounts of memory.
Running the sample with java -server -Xmx1024 causes an OOM of native heap after some time.
The problem is StrikeCache uses SoftReferences, which are very seldom cleared by the hotspot-server.
Probably a better idea would be some kind of "soft limit", however I don't have an implementation.
In the xrender pipeline this is solved using a hard limit.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
StrikeCache should limit the amount of native memory used.
ACTUAL -
The JVM OOMs as soon as the process hits the 2GB barrier, on a 32bit system - and consumes extremly huge amounts of memory on 64-bit systems.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.image.*;
import java.util.*;
public class FontOOMTest {
public static void main(String[] args) {
Image bImg =new BufferedImage(1024, 1024, BufferedImage.TYPE_INT_RGB);
Graphics2D g = (Graphics2D) bImg.getGraphics();
Random rand = new Random();
while(true) {
g.setFont(new Font("Dialog", Font.PLAIN, rand.nextInt(100)));
g.rotate(rand.nextDouble()%100);
g.drawString("qwertzuiopasdfghjklyxcvbnnnnmQWERTZUIOPASDFGHJKKKLLYXCVBNNM12345678990", 512, 512);
}
}
}
---------- END SOURCE ----------
- duplicates
-
JDK-6927458 font system should cache transient strikes with weak references.
-
- Closed
-