> From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
