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
#

Use classic VM. But, one will lose all the new features and improvements
in hotspot compiler.

 xxxxx@xxxxx  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.

 xxxxx@xxxxx  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.

I seem to be getting the same thing, but our project is so 
complex that I can't narrow it down very well. We seem to 
be losing hundreds of megabytes of memory, yet when I used 
OptimizeIt to try to figure out where that memory was 
going, it didn't seem to be going anywhere. To make matters 
worse, our project does not run without HotSpot for some 
reason. (gets a ClassCircularityError) In fact, VM just bit 
the dust with the following error:

#
# An EXCEPTION_STACK_OVERFLOW exception has been detected 
in native code outside the VM.
# Program counter=0x5025c2c7
#
Exception java.lang.OutOfMemoryError: requested 16000 bytes

Also, I have plenty of free memory, so I can't figure out 
why I am getting these errors.

I am facing the same problem with application.After memory 
reaches the maximum heap the jvm stops allocating new 
memory for the objects and going to outof memory 
error.Optimizeit and Jprobe does't showing any memory leaks 
in the application code.Please fix this bug immediatly

I have noticed similar when running
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition
Java HotSpot(TM)
Although not thru HTTP only thru HTTPS.

I would be very iterested in a solution to this, I do not 
get out of memory errors, probably due to the size of page 
file we have allocated and the 1gig of memory in the 
server, but it blows the heap size within minutes and 
reaches about 600meg in less than 1 hour.

I've run into the same problem. Are there any other 
workarounds (other than running with -classic)? Is it a 
leak in a particular API? Or do certain programming 
constructs cause it?

try using IBM's JDK... 

We also see a huge memory leak (2 MB every minute - as 
reported by task manager) with our Java application when 
used with Java HotSpot(TM) Client VM 1.3 instead of Classic 
VM. Our application has a lot of repainting of AWT/Swing 
components to do after every few seconds. 

Optimizeit4.0.2 does not report the increase since it uses 
Classic VM internally for profiling. HotSpot Client VM 
(1.3) does not have the necessary profiling API. However, 
the JDK 1.3.1 version is supposed to have it and OptimizeIt 
should also catch the leak. This bug needs to be fixed 
immediately.

We are also seeing something similar in a large heap 
application using jdk1.3.0 under NT4 SP6 with 1.5GB 
physical memory.  Oddly, we can set Xmx1100m to set the max 
heap to 1.1GB but the java.exe process can consume much 
more, up to 1.5GB before a full GC frees the memory.

Does anyone know if this problem has been looked into for 
jdk1.3.1 ?  This is really a disaster for "Enterprise" 
software.

We also had this issue; we resolved it by switching to IBMs 
JVM.  Performance for our application was competitive with 
HotSpot Server VM.

We've run into the same problem with JDK 1.3.0 on Solaris 
2.7.  We have to restart the jvm every so often before it 
runs out of memory.  And there is no classic VM available 
on Solaris for 1.3.  This bug really adds a lot of OA&M 
overhead, and it should be fixed ASAP!!

This is a real show stopper. Our application make heavy use 
of AWT, 2D and Image Compression and on Win32 (Windows 2000 
Advance Server) platform it eats up heap like anything even 
with a garbage collector thread trying to cleanup the 
unused objects. In the end it give java.lang.OutOfMemory 
error and JVM crashes.

This needs to be fixed ASAP. 

This bug happens constantly for us; we can reproduce it any 
time, on both client (AWT) and server pieces in Windows 
environment. It is a real showstopper - we cannot use 
hotspot with this bug.

Hi I am getting the same problem even when running with OptimizeIt, and when
running with OptimizeIt the problem shows even much earlier than when running
without.
From what I see the problem shows up mainly just before a Full GC is about to be
started by the JVM and although sometime then running with OptimizeIt I was able
to recover most of the time the JVM would either freeze completely or terminate.

Unfortunately I am unable to give a test case due to the complexity of the application.

I don't quite understand the evaluation statement. We are 
seeing this on customer premises; it's a matter of 4 days 
to fill up 1.5 GB of physical RAM by JAVA.EXE process and 
terminate the process. We've been digging all over the 
place in our Java code and we couldn't figure out what was 
wrong. This should really be a high priority issue. 

Try installing the JDK1.3.1, the Solaris 1.3.0 Hotspot VM 
crashed under heavy usage for me with both Signal 11 and 
Out of memory errors, and all problems were fixed when I 
installed the JDK 1.3.1 and the Solaris system patches. 

Well, Ya'll can add me in the list. My heavy swing 
application running in nt sp6 will grow to 110meg and then 
outofmemory errors. I am using Xms64mb Xmx64mb and using 
hotspot in jdk1.3 . Also, I notice that even -verbosegc 
showing some memory reduction but task manager showing no 
memory being released at all ???

I too seem to have the problem with the memory leak. 
However, when trying to track the problem with JProbe, 
we don't seem to be able to find anything. This bug 
could be the reason for this! This is a major problem 
for one of our customers!
Question for Sun: does the Java Server Hotspot version 
also have this problem?

In windows,memory increasing is a big problem!

This bug was reported over 7 MONTHS ago! It's still not 
fixed? In the real world a bug this serious left for 7 
months would mean the company responsible would be out of 
business... while in the meantime Sun touts Java as 
reliable and robust? Bah. I wish we hadn't jumped on the 
Java bandwagon, but now we're stuck with it. Not even MS 
would behave like this!

Us too I'm afraid. Servlet under JRun just keeps notching 
up the memory and eventually keels over. Kind of limits the 
usefulness of a website if you have to restart it every few 
hours.

I saw the same thing running Tomcat with jdk1.3.1 and the hotspot server compiler
on my nt box.  However this only occured when I had seti@home command line
version running.  Turned off seti and problem went away.  I'm wondering if there
isn't a common system dll on NT that has a prob being accessed by two apps.

I am having this very problem under Linux. I have a program
which uses a Genetic algorithm to simulate 'games', and
after a couple of days running I start getting OutOfMemory
errors. I have tried 1.3.0, 1.3.1. I can't use IBM's jdk
because it seems to leak memory on _ALL_ apps I run with it.
I also ran JProbe on it, and it showed no signs of memory leaks.

Hi All,
Has anyone found this problem to go away with JDK 1.3.1_01 
on Solaris? I saw a posting (Bug ID 4412393)recommending 
this as a solution.

FINALLY!!! I have been going crazy trying to find what the 
leak is from.  I too have optimizeIt and see absolutely 
nothing, my system uses RMI and serialization so this is 
good to know.  I had no idea where to look.  I will try the 
jdk 1.3.1 or the -classic option and report back.

Hi guys.

I got an out of memory Exception while bringing WebLogic 
5.1 Server with jdk 1.3.1. Interestingly the problem comes 
when i use the -server flag (Server VM for jdk1.3.1), while 
if i use the -hotspot flag (client VM for jdk 1.3.1) this 
problem is never confronted. The Server eats memory like 
Godzilla, and crashes within a few minutes. 

Try using the -Xincgc argument with HotSpot
to use the incremental garbage collector.  It
uses a bit more memory in general, but it *will*
release memory back to Windows after the GC has
freed it.

We continue to see simplar problems with 1.3.1-b24 on our 
1.5GB NT4 boxes.  We are suspicious of the AWT code that we 
are using in our server app because when we do get a 
Illegal_access_exception, Dr Watson always follows it back 
to code in AWT.  Like was reported by others, OptimizeIt 
isnt helpfull in finding the problem.  Currently, our app 
servers will run safely for about 7 days before getting 
OutOfMemoryError's.

Add us to the list. We too are writing a sizeable server 
app, and are consistently seeing OutOfMemory problems after 
a short while. OptimizeIt reports no problem at all (we had 
numerous retention problems a first, but fixed them all), 
yet VM heap keeps shooting up until it can no more. Very 
unfortunate. Java is great. Performance is OK nowadays. 
Please let's get this memory leak out of the way. 
What I learnt in this forum is that I will try -Xincgc and -
classic. Will report back if this helps. 
One question that keeps puzzling me: If W2K TaskManager 
reports increasing mem usage, is that because it allows the 
app to consume more as long as there's enough memory left? 
Would it refuse extra memory after a while, forcing GC to 
become more aggressive? Maybe stupid question, but there's 
something fuzzy about how memory gets allocated. Sometimes 
VM heap peaks up while there's no need for extra memory at 
all - at least not according to OptimizeIt (4.02).

We are also encountering behavior that sounds like this, on 1.3.1_01 on both Win2000 and Solaris.  Running with -server,  using Tomcat.  It's a fairly complex app, and the same sequence of events doesn't always generate the bug, so providing a reasonable test case is well nigh impossible.  I may try -incgc or look into the IBM JDK.

Has anyone tried this on 1.4 beta2?

I'm pretty disappointed that, as far as I can tell, Sun is giving no priority to this bug whatsoever when it's the most-voted for on the Bug Parade... beating the next bug by 2x.  Yeesh.

Well, adding -Xincgc didn't help.  Still get it (this is on:
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Server VM (build 1.3.1_01, mixed mode)

-classic or IBM JRE is out for us, production platform is
Solaris.  This is a serious problem.

I had similar problems, and I switched to IBM JRE 1.3 and I 
haven't seen the out of memory problems. Also the 
performance with IBM is like 30% better than Sun.

Our app does a lot of XML parsing, too.

We've had similar problems under 1.3.1_01 for some time, 
too.  Our production env is Solaris, so no -classic 
available. (I just tested under Linux 2.4.2, similar 
problem.)

Our server-side app exercise a lot of JMS MQ (Fiorano) and 
JDBC (Oracle) transactions.  It executes many Python codes 
under JPython, too.  Developers tried very hard to stamp 
out any app memory leak, but memory usage still grows 
steadily, although rather slow.  Similar behaviours were 
observed when RMI was used in place of JMS; we actually 
tested the JMS codes alone and didn't see much memory usage 
growth.  Behaviour on Linux is somewhat different from on 
Solaris, but memory usage grows on both. (Linux JVM on 
inferior hardware yields better throughput and exerts less 
system load, but the same amount of memory lasts longer in 
Solaris VM; may be due to the way Linux handles threads.)

Here's an error message from a recent test on Linux:
java.lang.OutOfMemoryError: unable to create new native 
thread
        at java.lang.Thread.start(Native Method)
        at 
fiorano.jms.runtime.ptp.FioranoQueueSession.checkStartRequir
ed(Unknown Source)
        at 
fiorano.jms.runtime.ptp.FioranoQueueSession.startSession
(Unknown Source)
        at 
fiorano.jms.runtime.ptp.FioranoQueueConnection.addSession
(Unknown Source)
        at 
fiorano.jms.runtime.ptp.FioranoQueueConnection.createQueueSe
ssion(Unknown Source)

I'd like to know if there's a solution/conclusion.

I suffered a problem that had similar symptoms. What I
finally figured out was that all the memory was sitting
around waiting to be finalized. I had many threads
creating garbage that needed to be finalized (on a multi-
processor server), and apparently on a single "low-priority"
finalizer thread trying to clean up after the fact. My
workaround consists of this code (which I call each time
my servlet is invoked):

    /**
     * A class to make the finalizer thread max priority.
     */
    public static class finalizer_max {
        public void finalize() {
            Thread.currentThread().setPriority
(Thread.MAX_PRIORITY);
        }
    }
    
    /**
     * True if finalize already fixed.
     */
    private static boolean finalize_fixed = false;
    
    /**
     * Fix the finalize problem.
     */
    private synchronized static void fixFinalize() {
        if (!finalize_fixed) {
             // Initialize the finalizer thread. We need to 
bump up the priority
            // to make sure stuff gets finalized            
            finalizer_fixed = true;
            new finalizer_max();
            System.gc();
            System.runFinalization();
        }
    }

Please fix this asap looks still is not working for N4 S6 
in 1.4 beta

Looks like the hot-spot is build in a way it never let the 
garbage colector runs on complex threads applications. It 
does not matter how many times I call the gc or 
runFinaliztion these are never launched before I get the 
outofmemory error. The only solution I found is the 
sugested by rcollinsrealsport, of course I twik it to fit 
my application needs. Sun needs to create an instruction to 
force the gc or runFinaliztion for the java 1.4. .... 
Meanwhile I may need to depend on this artificial high 
priority thread to run the gc... Also Sun needs to create 
an instruction to disable/enable the garbage collection if 
requested by the program.. I hope Sun can add this to the 
1.4 before release...

good luck

Finally a light at the end of the tunnel....
this is a workaround for NT...
looks like the bug is some kind of disinchronization 
between the java virtual machine and the dll and memory 
manager of the NT OS... what I did is treat java like C++ 
every time I left a method, before leave it I set all the 
local variables to null, then call the gc()... including 
before any dispose().. on the for statements if there is 
any new object before new the object, set the object to 
null... and have also the high priority thread to force the 
gc to run... and as last resource have a continuos thread 
checking memory available and free... in case of risk of 
outofmemory error... relaunch the service (shut down the 
java virtual machine... save any important object as 
serializable and status of the current state of the 
application) and initialize the service on a new java 
virtual machine, recover the critical objects and status... 
and last verify this is process is only for NT using 
getProperties("os.name") looking for the "NT" string... 
this does not fix the bug... however guaranties that the 
service is allways running on NT...

I have tried rcollinsrealsport and other techniques like 
setting to null and it doesn't seem to have much impact.  
The only thing that has worked is running in -classic mode 
but that SUCKS!!!!  Too slow.  Sun fix the GodDa*&@$ 
problem!

tien-lung.liu@atl.frb.org

Has anyone been successful in running in -classic mode? We tried to edit JDK1.3.0_02/jre/lib/jvm.cfg and 
put the "-classic" line before all the other options and restarted the server, but the server still eats memory 
like crazy.  

WE too have the same problem with our application crashing 
after 1-2 hours running with HOTSPOT on. We tried alot of 
suggestions found in the HotSpot-performance FAQ & GC 
Tuning guidelines, but is NOT HELPING at all. 

Sun ought to do something to fix this bug/basically make 
HOPTSPOT stable for PRODUCTION use.

I am seeing this problem on Windows NT 4.0 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)

Absolutely unacceptable. The client throws OutOfMemory 
exception after a few hours of functioning. What is this 
classic mode? How do I set it on Windows platform? Thanks.

I am able to reproduce this bug fairly easily. I run Tomcat 
with the -server option being sent to the JVM. I can use 
jakarta-jmeter to hit two urls in my servlet over and over. 
with 8 threads doing this I get the jvm to throw an 
OutOfMemoryException (OOME) in about 45 minutes.

The exception occurs in CompileThread0. The OOME is asking 
for 402653192 bytes. It doesn't get it. Interestingly two 
runs both produced the same memory request. 

Runtime.totalMemory() never reported the max allocated 
memory was reached (specified with -Xmx48m) and 
Runtime.freeMemory() always reported some memory available. 
Free memory went up and down without any explicit calls to 
gc. (Unless TC calls gc on occaision)

The IBM jdk 1.3.0 didn't have this problem. It ran faster 
and for twice as long (before I stopped the test run).

I am also getting sick of this bug.  I am currently working 
on a large swing app and every now and then I need to 
restart the JVM and my ide due to the hard drive cranking 
and memory shortages.  I'm going to try the IBM JDK, hope 
it helps...

I'm also hitting the same OutOfMemoryException when using -
server option.  The amount it tried to allocate is 
402653192 bytes and coming from the CompileThread0.  I'm 
using Macromedia JRun 3.1 and Sun JDK 1.3.1 on Wintel box.
Please fix it..

Although the Hotspot VM most likely leaks memory, using 
OptimizeIt is not the best way to determine if your program 
is the cause of the leak.  I worked on a large project once 
where some unremoved listeners were causing a leak, and 
they did not show up in OptimizeIt at all even though they 
should have.  I then tried JProbe and quickly found the 
prolem.  Also JProbe has better heap inspection tools.  I 
reccommend giving it a try befor giving up all hope.

Have had similiar problems with memory leaks on Solaris 
since mid 2000. At first we thought it was our App Server, 
then looked at the caching product we use. Finally it came 
down to the JVM. This is a long standing widespread problem 
and yet from Sun's response it appears they believe it to 
be inconsequential. Maybe what they are saying is they 
don't have a clue??? or maybe the bug reports are not taken 
seriously. This memory leak issue along with RFE 4466510 
dealing with too large a memory footprint are at the top of 
my list. Most other problems have work arounds but these 
need #1 priority attention.

mpontillo,
If your program runs out of memory and you think it should 
not, for its size then the failure to malloc would have 
been most probably caused by a system level limitation on 
the size of the program in memory.

I seem to have the same problem.  JProbe 3.0 does not show 
any leaks.  I am having this problem on both JDK 1.3 and 
1.4 beta 3. Happens with IBM and Sun JVMs.  The happens in 
both classic and hotspot client/server VMs.  

The listed work arounds have been helpful, but not a 
complete solution.  The issue has to do with GC during 
multiple threads with heavy processing on a multiprocessor 
box.  I have gotten the best results by creating a 
background high priority thread as previously suggested and 
watch the free memory.  If free memory drops below a 
certain threshold (right now I am using 30% free memory 
remaining) then I loop doing gc() runFinalization() until 
the free memory goes above the threshold.  The other side 
of this I have my long running threads call a method on 
this GCThread that will cause them to block while we claim 
more memory.   By forcing the other threads to temporarily 
block, I think I am allowing more memory to be freed.  I 
have further testing, but if this works, I will let you 
know.

For any Sun folks out there...  This has been open a very 
long time and does not appear to have any momentum by Sun. 
How does Sun expect us to make Java long running servers if 
it can not account for these acquisations.  Either say it 
is not you and here is why, or say we know what you are 
talking about and can not fix it at this time.  

If I can narrow this down to an example that I can send 
you, then I will, but until then I would expect someone 
from Sun to jump on this.  It has been a year and no 
technical comments?

If anyone has fixed this or worked around it, please post 
updates.  Thanks!
Dave

Oops...try that again in a more readable form:

I am having the same problem, too.  I am using linux, so
thread priority doesn't have any effect.  This may be a
stalled gc thread, but I suspect it is more than that.  When
I run my program (an RMI-based server application), memory
usage will increase indefinitely, until Linux sends a kill
signal to the process, as long as requests keep coming into
the server.  But if there is a break in the requests,
garbage collection kicks in and memory use drops again,
according to /procs/<pid>/stats.  

*However*, when I look at the memory use as reported 
by top, nothing is freed.  The
only thing that happens when the requests to the server
subside is that the memory consumption stops increasing. 
And as soon as server requests start coming in, memory
consumption starts increasing again--immediately.

Eventually, Linux decides that the app has too much memory,
and sends it a kill signal. 

I've tried this with Sun, IBM,
and Blackdown 1.3 VMs, and the 1.4 betas.  I've tried
-classic, -Xincgc, and I've used JProbe to confirm that
there is no leak in my code (e.g. stray references to
objects).  Nothing seems to work. 

I know that the JVM can't
really give memory back to the Linux OS, but it should be
able to reuse the freed-up heap space that appears after gc
and finalization.  It looks to me like this isn't
happening--somewhere in there, something is allocating
memory in a way that forces the JVM to ask for more memory
from the OS, even though it has plenty of spare room on the
heap. If I had to take a guess, I would say that this
problem is happening somewhere during some low- or mid-level
networking operations, since virtually everyone who has
posted to this list is running some kind of
server/servlet/rmi app. 

To repeat what has been said by a
lot of others: this bug has been open for a long time, and
is causing a lot of us grief.  Even if the bug isn't yet
fixed, it would be really nice if someone at Sun could
confirm that somebody is still looking for a solution to
this.  Actually, it would be nice to hear any kind of
comment whatsoever from the Sun folks re: this bug!

I am having the same problem, too.  I am using linux, so thread priority doesn't have any effect.  This may be a stalled gc thread, but I suspect it is more than that.  When I run my program (an RMI-based server application), memory usage will increase indefinitely, until Linux sends a kill signal to the process, as long as requests keep coming into the server.  But if there is a break in the requests, garbage collection kicks in and memory use drops again, according to /procs/<pid>/stats.  

*However*, when I look at the memory use as reported by top, nothing is freed.  The only thing that happens when the requests to the server subside is that the memory consumption stops increasing.  And as soon as server requests start coming in, memory consumption starts increasing again--immediately.

Eventually, Linux decides that the app has too much memory, and sends it a kill signal.

I've tried this with Sun, IBM, and Blackdown 1.3 VMs, and the 1.4 betas.  I've tried -classic, -Xincgc, and I've used JProbe to confirm that there is no leak in my code (e.g. stray references to objects).  Nothing seems to work.

I know that the JVM can't really give memory back to the OS in Linux, but it should be able to reuse the freed-up heap space that happens after gc and finalization.  It looks to me like this isn't happening--somewhere in there, something is allocating memory in a way that forces the JVM to ask for more memory from the OS, even though it has plenty of spare room on the heap.

If I had to take a guess, I would say that this problem is happening somewhere during some low- or mid-level networking operations, since virtually everyone who has posted to this list is running some kind of server/servlet/rmi app.

To repeat what has been said by a lot of others: this bug has been open for a long time, and is causing a lot of us grief.  Even if the bug isn't yet fixed, it would be really nice if someone at Sun could confirm that somebody is still looking for a solution to this.  Actually, it would be nice to hear any kind of comment whatsoever from the Sun folks re: this bug!

It is a big bug.We meet it everyday.And I am so sad about 
it.Please fix the bug.

We see similar issues with Jre 1.3.1_01 on Solaris 8 with patches as suggesed. We also tried with Xint to do 
just use interpretive mode as well. This is in use in combination with Weblogic 5.1 ServicePack9. I also see  
the problem with 1.2.2_05 on Solaris 6 with Weblogic 5.1 SP9. It also happens on Linux with Weblogic Sp9

The problem exists and may be Sun and BEA shoud sit together some more and fix it. There are enough 
people complaining abou this problem. Some are even begging for a fix for this. Is this going to to go away if 
we try _02, _03 etc., or 1.4...Amazing this is going on for a full year..Hope 2002 is better

I encountered the same problem and tried many suggestions 
in vain. As a desperate move, I am trying to install HotSpot
1.0.1 on top of JDK 1.2.2 on Solaris to see if it works. But
I am getting "Unable to load library libjava.so" even
though LD_LIBRARY_PATH was set to include a correct path to
libjava.so. I tried to install HotSpot 1.0.1 on the 
reference
implementation (JDK1.2.2_008) and release implementation
(jdk1.2.2_08, jdk1.2.2_09, jdk1.2.2_10) and got the same
error message. If anyone was successful in doing this, I 
would appreciate your help. Or Is this worth to try?

-Pyung

This has been so frutstrating to see this bug hanging 
around for so long. Whats the use of using so called easy 
develoment environment(Java) if we spent 80 % of the time 
in solving these issues. I was better off with C++ where I 
spent 80% of time in coding & 20% with these kind of memory 
leaks.

We solved the outofmemory problem by increasing the swap file size on the server. No more bouncing the 
server every day.