compilation of java for 64 bit
in [Java Help]
|
Prev: sha256sum and (new BigInteger(1, MD.digest())).toString(16) not listing exactly the same ...
Next: JPA+hibernate merge vs find fetching lazy collection
From: Peter Duniho on 27 Dec 2009 18:35 zigzagdna wrote: > [...] > It does show java.exe can now exceute >2GB address space. When one > installs it from Sun's web site, it doe snot have that capability. Okay, so you've demonstrated for yourself that Java as delivered is not large-address-aware, but that you can set that flag. Keep in mind my previous point: there is no guarantee that setting the flag will result in a stable application. The application may, intentionally or unintentionally, depend on pointer values remaining within the 31-bit, 2GB range. Java is just like any other application in this respect. Use this setting at your own risk. Frankly, I would _never_ consider using that setting on an application outside my own control for anything remotely important. And for Java, given that there is in fact a 64-bit version available and you're running on a 64-bit OS, to do so seems especially foolish to me. I would be surprised if you can find a significant enough performance difference between the 64-bit and 32-bit JVM versions to justify running the 32-bit JVM with the large-address-aware flag forced on. Pete
From: Kevin McMurtrie on 27 Dec 2009 18:45 In article <hh8qjd$uti$1(a)news.eternal-september.org>, "Mike Schilling" <mscottschilling(a)hotmail.com> wrote: > zigzagdna wrote: > > Looks like safest way is to use 64bit jvm when on 64 bit OS, however > > it runs slightly slower > > Read it more carefully: *may* run slightly slower. > And the original post said it could be faster. I've generally seen the x86-64 JVM run faster than the x86 JVM. I'm sure micro-benchmarks could show it going either way. -- I won't see Google Groups replies because I must filter them as spam
From: Lew on 27 Dec 2009 19:15 zigzagdna wrote: > Looks like safest way is to use 64bit jvm when on 64 bit OS, however > it runs slightly slower than 32bit JVM on 64bit OS unless one is > taking advantage of larger physical memory on the server. Says who? Have you tested this yourself? On your app mix? Have you used the "-XX:+UseCompressedOops" flag to the JVM? -- Lew
From: Owen Jacobson on 27 Dec 2009 19:38 On 2009-12-27 17:50:38 -0500, zigzagdna <zigzagdna(a)yahoo.com> said: > On Dec 27, 4:54�pm, Owen Jacobson <angrybald...(a)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
From: Peter Duniho on 27 Dec 2009 19:59
Owen Jacobson wrote: > 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. Not counting, of course, the fact that in 64-bit Windows the last range of addresses, from 3GB to 4GB, is also available to the process (that's a bit of a difference from the layout one would find under 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. Note that all of the above assumes a contiguously allocated heap. In theory, there is nothing that _requires_ Java to implement the heap that way. I don't even know what the actual implementation in Java is for the heap, but even if today it manages the heap as a singly allocated memory block, there's not any reason I'm aware to believe that would always be the case. And even today, it might not. So, a reserved section of the address space may or may not be a genuine issue. The more serious problem is that of setting /LARGEADDRESSAWARE for a program that is not, in fact, large-address-aware (where "aware" means that the authors of the program wrote the code with the expectation that pointers would use the full 32-bit range�by definition, if that flag isn't set, the program isn't large-address-aware). Pete |