tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <>
Subject Re: Tomcat 4.1 ignoring -Xmx params
Date Tue, 28 Jan 2003 19:06:03 GMT
> From: "Christian Cryder" <>
> Sent: Tuesday, January 28, 2003 9:26 AM
> Subject: RE: Tomcat 4.1 ignoring -Xmx params

> Ok, so this _is_ what I'm basing it on (looking at MS's Task manager).
> still doesn't seem reasonable that the actual memory used is 150
> > than the limit specified to the JVM. In other words, if I tell the JVM
> "-Xmx512" and the OS Task Mgr is reporting that Tomcat is using 670 MB,
> doesn't this seem like more than just an overhead issue?
> I'm perfectly content if that is in fact the answer, I'm just trying to
> confirm whether or not we have a problem.
> Any suggestions?

To be blunt, you don't have a problem, you have a discrepancy.

The first point is that, simply, Tomcat can not ignore or override the -Xmx
parameter simply because it's a parameter to the JVM over which Tomcat has
no control. Barring abuse through the use of JNI libraries, Java programs
simply don't have this kind of control of the JVM.

Now, what you are seeing is a side effect of the how the JVM operates.
Perhaps it's being used for garbage collection. Perhaps it's being used for
I/O. Perhaps it's the OS allocating buffers to the process for some other
reason. Who knows.

Plus with modern virtual memory operating systems, simple, hard memory
numbers are almost impossible to find. A simple example of that (though
unrelated to this) is a question on BSD systems as to "Why don't I have any
free memory?". The answer is because the system allocated it to be used as
disk buffers. So, while the system says you don't have any free memory, what
it's not saying is that it's willing to immediately accomodate any user
request for more memory by dipping into its self-manage file cache.

The point is that with so much going on in the background of modern systems,
memory comes and goes like the wind.

So, while Xmx512 may limit the JVM heap, it does not necessarily limit the
JVM process size. They are two different numbers.

Now, one would like to hope that the process does not grow without bound.
For example, if you use the new file mapping classes in the 1.4 JDK, you can
expand the JVM process size far beyond the actual heap size. (At least I
think so, I can't fathom why the JVM would create an actual heap object out
of a mmap buffer...what would be the point?)

I would consider the Xmx value to be an "inspiration" to the JVM to keep it
in check, but not a hard and fast rule as to how the process will get.


Will Hartung

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

View raw message