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