MappedByteBuffer
in [Java Help]
|
Prev: swing html parser
Next: Class Constants - pros and cons
From: Alan Gutierrez on 23 Jul 2010 16:59 Patricia Shanahan wrote: > On 7/23/2010 10:42 AM, Peter Duniho wrote: >> Nigel Wade wrote: >>> [...] >>> In a 32bit application your maximum address space is 4GB, and could be >>> a good deal less than that due to system dependent memory limitations. >>> Thus, your attempt to allocate multiple regions of that address space in >>> blocks of 256MB will have a limited amount of success, depending on what >>> contiguous regions of the address space are currently available. >> >> Indeed, it's worth pointing out that on Windows, the maximum address >> space for Java programs is only 2GB, and really only about 1.5GB (give >> or take) after various overhead involved in a Windows process and Java. >> And of course, any interesting program will have to allocate other >> memory objects, reducing that further (through both just the use of >> memory and fragmentation of the virtual address space). > > I assume when you say "on Windows" you mean "on 32 bit Windows"? I assume you're implying that 64 bit Windows has the same advantages as 64 bit JVM as noted by Nigel Wade? -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Arne Vajhøj on 23 Jul 2010 19:43 On 23-07-2010 01:30, Kevin McMurtrie wrote: > Java 1.5 is more commonly a 32 bit process while Java 1.6 is more > commonly a 64 bit process. For Sun Java then: Windows Linux Solaris not SPARC 1.6 latest both avilable both available both available 1.5 latest both avilable both available both available 1.4.2 latest only 32 bit only 32 bit only 32 bit So I can not see why it should necessarily be that way. Arne
From: Peter Duniho on 23 Jul 2010 19:58 Patricia Shanahan wrote: > On 7/23/2010 10:42 AM, Peter Duniho wrote: >> Nigel Wade wrote: >>> [...] >>> In a 32bit application your maximum address space is 4GB, and could be >>> a good deal less than that due to system dependent memory limitations. >>> Thus, your attempt to allocate multiple regions of that address space in >>> blocks of 256MB will have a limited amount of success, depending on what >>> contiguous regions of the address space are currently available. >> >> Indeed, it's worth pointing out that on Windows, the maximum address >> space for Java programs is only 2GB, and really only about 1.5GB (give >> or take) after various overhead involved in a Windows process and Java. >> And of course, any interesting program will have to allocate other >> memory objects, reducing that further (through both just the use of >> memory and fragmentation of the virtual address space). > > I assume when you say "on Windows" you mean "on 32 bit Windows"? No. Without "large address aware" (Java is not, as delivered, "large address aware"), 32-bit processes are limited to 2GB even on 64-bit Windows. If you enable "large address aware" (which you can do after the fact…so in theory someone could hack Java's .exe to have that flag set), then on 32-bit Windows, the limit goes up to 3GB, and on 64-bit Windows the limit goes up to 4GB. But out of the box, 32-bit Java is restricted to 2GB whether running on 32-bit Windows or 64-bit Windows. It may or may not be safe to run Java with "large address aware" enabled. One does so at their own risk. In theory, it should be fine. In practice, you'd have to look carefully at the JVM source code to know for sure. Pete
From: Arne Vajhøj on 23 Jul 2010 20:32 On 23-07-2010 19:58, Peter Duniho wrote: > Patricia Shanahan wrote: >> On 7/23/2010 10:42 AM, Peter Duniho wrote: >>> Nigel Wade wrote: >>>> [...] >>>> In a 32bit application your maximum address space is 4GB, and could be >>>> a good deal less than that due to system dependent memory limitations. >>>> Thus, your attempt to allocate multiple regions of that address >>>> space in >>>> blocks of 256MB will have a limited amount of success, depending on >>>> what >>>> contiguous regions of the address space are currently available. >>> >>> Indeed, it's worth pointing out that on Windows, the maximum address >>> space for Java programs is only 2GB, and really only about 1.5GB (give >>> or take) after various overhead involved in a Windows process and Java. >>> And of course, any interesting program will have to allocate other >>> memory objects, reducing that further (through both just the use of >>> memory and fragmentation of the virtual address space). >> >> I assume when you say "on Windows" you mean "on 32 bit Windows"? > > No. Without "large address aware" (Java is not, as delivered, "large > address aware"), 32-bit processes are limited to 2GB even on 64-bit > Windows. > > If you enable "large address aware" (which you can do after the fact…so > in theory someone could hack Java's .exe to have that flag set), then on > 32-bit Windows, the limit goes up to 3GB, and on 64-bit Windows the > limit goes up to 4GB. > > But out of the box, 32-bit Java is restricted to 2GB whether running on > 32-bit Windows or 64-bit Windows. The IMAGE_FILE_LARGE_ADDRESS_AWARE is not the real problem. SUN Java requires contiguous heap space. And even with /3GB there are something around the 2 GB marker. BEA (now Oracle) JRockit allows non-contiguous heap and allows almost 3 GB heap with /3GB. And almost 4 GB for 32 bit JVM on 64 bit Windows. http://blogs.oracle.com/jrockit/2008/09/how_to_get_almost_3_gb_heap_on_windows.html Arne
From: Peter Duniho on 23 Jul 2010 20:39
Arne Vajhøj wrote: > [...] >> But out of the box, 32-bit Java is restricted to 2GB whether running on >> 32-bit Windows or 64-bit Windows. > > The IMAGE_FILE_LARGE_ADDRESS_AWARE is not the real problem. On 64-bit Windows, I think it is. > SUN Java requires contiguous heap space. And even with /3GB there > are something around the 2 GB marker. The /3GB switch (that is, the flag set for Windows itself…this works alongside 32-bit apps with the "large address aware" flag set) applies only to 32-bit Windows. On 64-bit Windows (where the /3GB switch is moot), I'm not aware of any address space boundaries that would cause a problem. Even on 32-bit Windows with /3GB in the boot.ini file, one may get more memory for their Java process if they hack the Java .exe to have the "large address aware" flag, because less of the first 2GB of virtual address space is taken up by overhead (i.e. a lot of it can go in the third GB of address space). But you're right that on 32-bit Windows, a 32-bit process isn't going to get a Java heap larger than 2GB (and likely not even as large as). > BEA (now Oracle) JRockit allows non-contiguous heap and allows > almost 3 GB heap with /3GB. > > And almost 4 GB for 32 bit JVM on 64 bit Windows. > > http://blogs.oracle.com/jrockit/2008/09/how_to_get_almost_3_gb_heap_on_windows.html That's awesome. Pete |