2
votes

Is there anywhere that a hostspot JVM process stores memory besides these places:

  • perm gen
  • tenured generation
  • eden space
  • from space
  • to space
  • code cache

That is to say: What possible ways are there that the hotspot process can reserve & commit memory on a machine such that said memory would not show up in the statistics for one of those places?

Some answers I can think of (let me know if these are true):

  • virtual memory used for thread stacks are not represented in those numbers
  • any loaded dlls or files.

EDIT:

some other answers given:

  • java.exe itself
  • JNI methods could allocate memory itself
  • any native code (eg. from dlls) could allocate memory.
  • general JVM metadata for running itself.
1
Native code will allocate its own memory. This strictly speaking runs outside the JVM but it will cause your program to use more memory then it is reporting in these numbers. - Boris the Spider
Keep in mind that all the above "spaces" are representative of one particular family of JVMs (Hotspot) -- there is nothing that says that every JVM has an "eden space" or a "to space". The three main spaces present in just about any JVM process are the main object heap, the heap used for class info and code, and the "non-Java" heap used by the JVM internals. (One could argue that the execution stack is another "space", or count it as "non-Java".) - Hot Licks

1 Answers

1
votes

You're correct so far (DLLs include all JNI libraries and whatever memory they've allocated). The VM also has its own code (e.g., the contents of java), bookkeeping information about the memory that's allocated to Java programs, and potentially memory used by VM agents. Basically, what you described in your first list are the items that make up the "running memory" of the virtual machine; the rest of the JVM's memory are all of the items that represent the virtual machine's "hardware", such as the libraries that connect it to the OS's networking, graphics, and so on.