Dear Eric: Nop, the GC process returns the memory to the memory pool allocated by the JVM, so the JVM never exhaust its memory resources. The Xmx parameter indeed indicates the maximum amount of memory from the system that the JVM can use and the IBM assertion is true, the JVM never returns the memory allocated to the system but don't fear, this is actually a standard design behaviour for this kind of processes!!
Regards Ing. Marco Antonio Castillo Chief Design Engineer Van Der Kaaden IT Consulting Guatemala, Guatemala C.A. tel: +502 22382710 mobile: +502 59186971 e-mail: mabcasti...@vdkit.net On Tue, Feb 8, 2011 at 10:27 AM, Robinson, Eric <eric.robin...@psmnv.com>wrote: > Saw this statement on an IBM web site: > > "Most JVMs grow towards the upper heap limit (-Xmx/-mx options) when > more memory is required, and do not return memory to the operating > system, even if the memory is no longer needed, until the JVM process > terminates." > > Is this true? If thought returning unneeded memory to the OS was what GC > is all about. > > -- > Eric Robinson > > > > > > > > > > > > > > > > > Disclaimer - February 8, 2011 > This email and any files transmitted with it are confidential and intended > solely for Tomcat Users List. If you are not the named addressee you should > not disseminate, distribute, copy or alter this email. Any views or opinions > presented in this email are solely those of the author and might not > represent those of Physicians' Managed Care or Physician Select Management. > Warning: Although Physicians' Managed Care or Physician Select Management > has taken reasonable precautions to ensure no viruses are present in this > email, the company cannot accept responsibility for any loss or damage > arising from the use of this email or attachments. > This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
