tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Probst" <>
Subject RE: Memory Usage and Garbage Collection
Date Fri, 03 Jan 2003 15:14:13 GMT
Hi thank you,

your reply calms me down again. I guess I got a bit confused by 
the preceding discussion.


On 3 Jan 2003 at 8:59, Shapira, Yoav wrote:

> Hi,
> There's clearly some misconceptions on the topic of garbage
> collection ;)  These questions come up very often it seems, on
> this list and others.
> >Please consider the following service() or doGet() or so of a
> >servlet:
> >
> >public void service(ServletRequest request, ServletResponse
> >response)
> >   throws IOException
> >{
> >  OtherObject otherObject = new OtherObject();
> >  otherObject.doThisAndThat(request, response);
> >}
> >
> >Do I have to place the following
> >otherObject = null;
> >before the end of service(). Doesn't otherObject be gc-ed
> >otherwise? I've never done this.
> You don't have to do this.  The otherObject's reference count is
> increase by one when you assign it.  When the method (service()
> above) returns, the reference count for otherObject is reduced by
> one.  If the reference count is zero, otherObject can be garbage
> collected.
> >What about the object instances, which
> >otherObject.doThisAndThat() creates? So far I've thought there
> >are no live references if otherObject gets gc-ed.
> If otherObject creates local objects, they'll be GCed.  If it
> modifies static objects, those objects stay in a different place
> anyways and don't get GCed when otherObject does.
> Back to what Craig mentioned earlier: earlier in the Java life
> time, classes could get GCed themselves.  That really earns you
> very little, so it was removed.  Nowadays demands on classloaders
> and their hierarchies can get very complicated, so re-introducing
> class GC would be difficult anyways.   
> A JSP is compiled into a servlet and then loaded into memory. 
> Its bytecode is present only once, and takes up relatively little
> space (usually).  You won't gain much from destroying that
> bytecode and de-allocating its memory.  Same thing for normal
> servlets obviouisly.
> What you need to do is tune your garbage collection.  With some
> exceptions, full GCs shouldn't run all the time.  Depending on
> your collector, partial GCs can run all the time.  You'd expect
> that from incremental and concurrent collectors.  If you're
> running on multiple CPUs and have a parallel collector but only
> one System.out log, you'd expect to see GC output there nearly
> all the time.
> So you should start playing with your heap (-Xmx), new generation
> size and ration (XX:NewSize, XX:MaxNewSize, XX:NewRatio),
> collector policy (-Xincgc, -Xconcgc, XX:UseParNewGC, etc.) and
> other parameters to see which gives you the best behavior.  Don't
> -Xmx over the physical RAM size.  See the VM options page at:
> One principle to keep in mind is that memory is cheap, or at
> least considered cheap when it comes to GC performance tuning. 
> The java heap is greedy overall, and this is intended to
> increaser performance. That's why it won't de-allocate space (and
> never return space to the OS) until necessary with the default
> mark/sweep collector.
> Make sure to record your verbose:gc output between runs so that
> you can compare behavior.  This is not typically easy to tell by
> instinctive feel. 
> Yoav Shapira
> Millennium ChemInformatics

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message