Why can't I allocate 2GB of heap to the JVM on Windows, Part 2

I got an email from Fredrik Paulsson asking about my previous entry concerning "Why can't I allocate 2GB of heap to the JVM on Windows?" Fredrik (and others) have asked about the new /3GB and /PAE switches available in certain releases of Windows (2000/2003, AS/ES).

There is a description of the /3GB switch over at the Microsoft website.

Anyways, the use of this switch does not enable the JVM to allocate more than 2GB heap on Windows. Why? (The Sun VM engineers can step up and correct me here if I'm wrong) The Java Virtual Machine wants a contiguous allocation of memory. The /3GB switch in Windows does not allow that. The use of non-contiguous memory space for the 32bit JVM would most probably cause performance issues. Can you imagine doing garbage collection over 3GB of non-contiguous RAM? \*shudder\*

So what is the solution? Honestly, if you're going to use big RAM, just upgrade to 64bit CPUs and a 64bit OS. Windows, Linux, and Solaris all come in 64bit versions now.

PS> According to one of the Java GC gods here at Sun, "The Java object heap has to be allocated in contiguous virtual addresses, for implementation reasons." (P.Kessler)
Comments:

I don't think the JVM requires a contiguous heap. On most systems it would be impossible to do that beyond a few megabytes, I think.

Posted by Keith Lea on July 19, 2004 at 05:05 AM PDT #

No P. Kessler is right (He's definitly the GC guy). You need contiguous memory to get super large heaps. And the best way to get >2gb is to move up to a 64bit CPU/OS.

Posted by Azeem Jiva on July 19, 2004 at 04:20 PM PDT #

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 Windohs, up to about 3.8GB on Solaris. YMMV.). On Windohs, 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.

I hope that helps.

... peter

Posted by Peter Kessler on July 22, 2004 at 09:53 AM PDT #

JRockit from BEA has promised support for the /3GB switch in their next release: http://e-docs.bea.com/wljrockit/docs81/portblty/tshoot.html#999078 But I suppose since they are more a server JVM they might have a different architecture or prioritize larger heaps. /Fredrik Paulsson

Posted by Fredrik Paulsson on July 23, 2004 at 01:16 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

moazam

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today