Sun JVM RAM Utilization Limit On Windows Explained
Many of us are aware that there is a memory use limitation for the Java Virtual machine on Windows operating systems. This is noted and mentioned in many blog articles and I had been looking for a more expanded explanation and possible respite from this issue. This is particularly interesting when we take into account the new /3GB and /PAE switches in Widows O/S’’s. There is a full explanation of these here on Microsoft’’s web site,
here. The essence of this is that on 32-bit operating systems the maximum size of contiguous memory is 2GB. The 3GB switch
gets around this but unfortunately not for the Sun JVM. Here is an explanation of why by one of the senior engineers at Sun: -
"The reason we need a contiguous memory region for the heap is that we have a bunch of side data structures that are indexed by (scaled) offsets from the start of the heap. For example, we track object reference updates
with a “card mark array” that has one byte for each 512 bytes of heap. When we store a reference in the heap we have to mark the corresponding byte in the card mark array. We right shift the destination address of the store and use that to index the card mark array. Fun addressing arithmetic games you can”t do in Java that you get to (have to
play in C++."
"Usually we don”t have trouble getting modest contiguous regions (up to about 1.5GB on Windows, up to about 3.8GB on Solaris. YMMV.). On Windows, the problem is mostly that there are some libraries that get loaded before the JVM
starts up that break up the address space. Using the /3GB switch won”t rebase those libraries, so they are still a problem for us."
"We know how to make chunked heaps, but there would be some overhead to using them. We have more requests for faster storage management than we do for larger heaps in the 32-bit JVM. If you really want large heaps, switch to the
64-bit JVM. We still need contiguous memory, but it’’s much easier to get in a 64-bit address space."
