tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Java +GC question
Date Mon, 25 Nov 2013 00:52:03 GMT
> From: André Warnier [mailto:aw@ice-sa.com] 
> Subject: Re: Java +GC question

> Whatever happened to the "Never change a running system" ?

What?  And not give people something to do?

> > It's a little odd in that there are very few minor GCs occurring.  This would 
> > imply that whatever objects the application creates are either quite large 
> > (and do not fit in the Eden space) or do not escape the methods that use them 
> > and are thus allocated on the stack rather than the heap.

> (I'll not even pretend to understand that)

Large objects: Objects are normally allocated in a portion of the heap called Eden space,
and are harvested from there to survivor space during a minor GC.  However, if an object is
deemed to be too large to fit in Eden space, it will be allocated directly out of survivor
space and never be handled in a minor GC.

Reference escape: If the JIT compiler can determine that the reference to a newly created
object is not used outside of the scope of a method (does not escape), it generates code to
allocate the object space on the stack of the method, not the heap.  Without the heap allocation,
no GC is needed to reclaim such allocations.

> Basically, my question was aimed at finding out if the way it was doing 
> GC's implied that we could gain some performance by increasing the Heap, 
> or re-allocating/distributing some parts of it.

I think it's highly unlikely you could achieve any measurable improvement, and you run the
real risk of making it much worse.  Using a larger heap would reduce the frequency of the
GCs, but since you're measuring 0.02 seconds every 15 minutes, you're well into the flattened
tail of the curve already.

> Any known (built-in) way of changing this to be real date/time timestamps, or add such
?

-XX:+PrintGCDateStamps

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message