JDK-4395735 : Memory leak with jdk 1.3 HotSpot compilers
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-12-07
  • Updated: 2022-10-21
  • Resolved: 2001-12-20
Related Reports
Relates :  
Relates :  
Description
Customer problem description:
------------------------------

One of our divisions  makes an XML integration product that integrates with 
our application server. It's got a servlet interface into the main engine of their product (called xCommerce).

When we hit this server with a load of HTTP requests (10 - 50
simulated users), the server leaks memory like crazy (about 1MB /
minute with 10 users). The memory usage of Silverserver.exe(java)
as reported by Windows NT Task Manager grows from 37mb to over
100mb.

This is running:

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
java full version "1.3.0-C"

I also see a significant leak in:

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Server VM (build 2.0fcs-E, mixed mode)
java full version "1.3.0-C"

All of these are on Windows NT 4.0 SP 6.

If I run -classic on  1.3.0, there is _no_ leak at all. The Memory usage
goes from 37mb to around 48mb and stays at that level.

If I put a System.gc() call into the servlet code so that it does a
GC on each request, we still observe the memory leak.

The death of the server is often an OutOfMemoryError, but I have
received the following from the 1.3.0 Client HotSpot VM:

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 53414645504F494E540E43505002EA
#




Comments
EVALUATION john.coomes@eng 2001-06-05 Customer reported that this problem occurs only vary rarely when running without OptimizeIt, and only in a development environment. Reducing the priority; keeping the bug open to track the remaining issue of getting them a VM with timestamp info as described in the comments. ###@###.### 2001-12-20 Original submitter was not able to create a test case or reproduce the problem except when running with OptimizeIt (which uses jvmpi, which has a *significant* impact on garbage collection). The closest thing to a test case is a suggestion in the JDC comments to run tomcat and hit a URL repetitively. Using tomcat 4.0.1 on jdk 1.3.0-C, repetitively ran through the included sample jsp's (which are admittedly very simple, but available) in multiple tight loops for over 15 hours on win/nt 4.0 sp3. Memory usage started at ~17M (no activity) and slowly grew to ~78M when running jsps, but then remained steady state. No continued memory growth was seen. Assuming the java object heap was expanded to the max size (64M in this case, the default), a process size of 78M is reasonable. Tomcat could likely handle this load using less memory if -Xmx were used to limit the max heap size. Closing as not reproducible for lack of a test case. Some possible causes of memory related problems: Finalization (mentioned in a JDC comment attached to this bug) - objects pending finalization can tie up siginificant amounts of space, so frequently created objects should not be finalizable. Joshua Bloch's excellent book "Effective Java" goes further; in "Item 6: Avoid Finalizers" it says: "Finalizers are unpredictable, often dangerous, and generally unnecessary. ... Finalizers have a few valid uses, which we'll cover later in this item, but as a rule of thumb, finalizers should be avoided." Further, System.gc and System.runFinalization "may increase the odds of finalizers getting executed, but they don't guarantee it." (http://java.sun.com/docs/books/effective/index.html) Linux thread creation failure (another JDC comment): this is unrelated to this bug; the OutOfMemoryError is not from lack of space in the java object heap. When a native thread cannot be created, there are 2 likely problems: the address space is exhausted so there is no virtual address range to map in the thread stack, or lack of swap space. On RH6.1 (and likely 6.2), thread stacks are fixed by the threads library at 2Mb each, so they can quickly consume virtual address space.
11-06-2004

WORK AROUND Use classic VM. But, one will lose all the new features and improvements in hotspot compiler.
11-06-2004