Re: compilation of java for 64 bit
On 2009-12-27 17:50:38 -0500, zigzagdna <zigzagdna@yahoo.com> said:
On Dec 27, 4:54?pm, Owen Jacobson <angrybald...@gmail.com> wrote:
More practically, the limiting factor for the Windows 32-bit VM is not
the available address space, but the available *continuous* address
space. For implementation reasons, the Hotspot VM's heap must be
continuous in the process's address space. 32-bit Windows processes
(whether or not /3GB is in effect, and whether or not they are
/LARGEADDRESSAWARE) have a small gap in the usable address space right
above the 2GB mark, which prevents the VM from creating a continuous
region larger than 2GB.
Thanks. I had seen the links in your mail before starting this thread.
I know Sun's java needs contigous space; while it is not avaiable in
32bit OS, it should be avaiable when running 32bit JVM on 64 bit OS.
Sadly not. 64-bit Windows runs 32-bit processes as much like 32-bit
Windows does as possible, which includes keeping that hole in the
process address space. A /LARGEADDRESSAWARE 32-bit program running on
64-bit Windows has an address space laid out exactly as it would on
32-bit Windows.
I did a little digging to substantiate my claim about a gap at the 2GB
line. While I was wrong in that the gap is owned by the *process* and
not by the *OS* as I originally claimed, the gap is still present.
Libraries are loaded into 32-bit Windows processes near and below the
address 0x7FFFFFFF, which is at the top of a non-/LARGEADDRESSAWARE's
usable address space... but smack in the middle of a
/LARGEADDRESSAWARE's usable address space. Various low-level Windows
DLLs are loaded at fixed addresses and *cannot* be relocated by the
loader to somewhere more convenient to the JVM's address space
constraints.
Keep in mind that this is about address space, *not* memory.
-o