Gap between task manager to JVM memory

[avihai marchiano]

Hey,

In task manager (virtual memeory) i see much more memory compared to the memory i see when i looking in JConsole?

Can someone explain about this gap?

Thank you

[Jeanne Boyarsky]

Avihai,
I would think JConsole doesn't report on the memory the JVM itself uses.

[avihai marchiano]

The memory that i see in Jprofiler.

There is a gap.

[Steve Luke]

What is the system you are on? Is it a 64 bit OS? Is your JRE 64 bit compatible? Is JProfiler 64 bit compatible?

With 64 bit machines you can have much more memory than 32 bit machines. Problem with this is that many applications are just 32 bit programs running in a 64 bit shell, so they can only see the 32 bit addressed memory, and they can't get to the rest that the system has available.

Just a guess though.

[Peter Johnson]

As Jeanne wrote, Task Manager (and any other operating system-based tool that reports process memory usage) reports the memory used by the java process. This includes the amount of heap allocated, the code for the JVM, the data structures used by the JVM, and so on.

Java-based tools, such as JConsole, VisualVM, and JProfiler, report on heap usage. This is always a subset of the full memory used by the java process.

[avihai marchiano]

Sure the heap is not all the size, but in some cases the gap is too big.

look on this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6193438

http://support.microsoft.com/default.aspx?scid=kb;en-us;293215

Do you know if there is an option to control on the java none heap size?

What will happen if the none heap size will be out of memory?

[Peter Johnson]

There is no way to control the non-heap portion of the JVM memory because that is already handled automatically by the operating system as the C/C++ code that makes up the JVM allocates/deallocates structures referenced by pointers.

The bug you referenced appears to be more about perceptions that reality. Yes, doing what was suggested can effect working set memory usage, but has no bearing on commit memory (man, I hope I have these terms correct, it has been quite a while since I delved deeply into Windows memory management).

As a basic example, if the JVM asks Windows for 200MB to allocate the heap, Windows marks 200MB of memory (in this case, RAM-size + page-file-size) as reserved (committed), but physically gives the JVM only a small chunk. This small chunk is what is reported in Task Manager as used memory. Then as the JVM uses more and more of the heap, Windows gives it more and more of its allocation of the 200MB. Typically, the full 200MB is never marked as in-use because a full GC will take place well before you get there.

The suggested fix in the reported bug is, after GC, to get Windows to mark the unused heap as not in-use. But note that the memory will still be marked as reserved - that is as part of committed memory.

In Windows, when the committed memory for all process hits the maximum system memory (RAM + page file), you get an out of memory error from Windows.

As I said, it has been a while since I studied Windows memory allocation in depth, so take the above with a grain of salt, but that is what I remember.