Name: rmT116609 Date: 02/28/2001


java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)

Windows 2000 Professional SP1

If I run the Java2Demo with HS Server, like this:

java -server -jar Java2Demo.jar

then I go to the "Clipping" page, it freezes, then the java heap grows insanely
(may be a memory management bug, the thing keeps climbing up to 500Mb of
virtual size) until the JVM finally dies:

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4A41564123414C4C530E435050001E
#
# Problematic Thread: prio=5 tid=0x9942d8 nid=0x348 runnable
#

The error is easy to reproduce, at least in my machine. Does not happen
without the -server switch.

The machine is a DELL OptiPlex GX110, single-CPU PIII-866MHz, 256Mb RAM
Windows 2000 Professional, with Service Pack 1 and MSIE 5.5-SP1.
I also have the brand-new DirectX 8.0a, probably relevant to Java2D.

I tried to analyse the bug. It turns out that I can trigger it in any page of Java2D.
Even in some pages that seem to work correctly (like Arcs&Curves), I only need
to mouse over the Texture Chooser to produce the problem. I think the bug wakes
up when some specific Java2D API is exercised.

The Java heap, which I can see with -verbose:gc and the demo's memory monitor,
does no grow abnormally. It keeps stable in the 7-8Mb range, so all memory allocation
must be native code memory or leaking. And I have some control over the situation,if
I move some other window over the demo's window (just after the bug is fired), the JVM
runs normally for some time, but it crashes later. It seems the secret is obscuring the
part of the animation that is doing bad things.

See line #9 in the console window(gif file attached), showing a scavenge GC that takes 1.84s. This
happened when I triggered the bug. The excessive time for this GC pass is probably
due to swapping, or some thead running amok.

Output from verbose:jni and verbose:class don't reveal anything weird.
Using "-server -Xint" eliminates the problem, seems related to the JIT.

It seems there is a debug build of hotspot (jvm_g.dll), how can I
activate this one to use the debug-specific -XX: switches?
(Review ID: 117021)
======================================================================