Real Memory and JBoss on a Mac

sammcgee Jan 24, 2008 5:35 PM

This is both a general and a specific question. Thanks for any help or information.

I'm running a J2EE app with JBoss 4.0.5 on a dual Intel Mac and "seem" to have a memory leak. I say "seem" because I'm not sure what to expect anymore.

The bottom line issue is that the "Real Memory" allotted to JBoss continues to grow until I get a OutOfMemory error. However, I have been running the YourKit Java Profiler and the Java garbage collection seems to be working the way it should. Or at least, after a reasonable amount of time, the heap memory sizes all return to their original numbers -- Allocated and Used.

I am purposefully stressing the system by creating very large Hashtables, so the Used memory (in YourKit) does get large quickly, and the Real Memory tracks this growth. But once the Java gc is done and Used memory drops back down, the Real Memory stays where it is.

The questions are:

Is this not unexpected? Should I expect the system to release the Real Memory after a certain amount of time or is its only option to grow until the app (JBoss) is restarted?

Is there a way to determine what it is that is taking up this Real Memory or to force it to be released without an app restart?

Anyone out there know of a JBoss memory leak that would explain this?

Thanks for any help.

1. Re: Real Memory and JBoss on a Mac

peterj Jan 24, 2008 5:58 PM (in response to sammcgee)

I assume that "Real Memory" is the current size of the Java object heap, and that "Used" reflects the amount of the heap in use at the time. In which case what you are seeing makes sense, especially if you are not setting min and max heap to the same value. (In other words, once the JVM uses some memory for the heap, it never gives it back to the OS, thus "Real Memory" will never drop.) "Allocated" might reflect how much memory the JVM has ask for, though not being familiar with the tool you are using I could not say. (Usually, the JVM will not use all of the heap memory it asks the OS for because it will run a major collection long before it has used up all of the heap, thus there is always a portion of the memory that has been requested that is never used, though the OS still keeps it in reserve just in case the JVM actually will use it at some point.)

My preferred mechanism to view the heap usage is to set -verbose:gc JVM option on the command line and analyze that output from it. This gives me a better idea of how the heap is growing, and can also be used to detect a possible memory leak.
Actions