Re: compilation of java for 64 bit
On 2009-12-27 15:11:36 -0500, zigzagdna <zigzagdna@yahoo.com> said:
On Dec 27, 2:31?pm, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.com> wrote:
zigzagdna wrote:
I am reading some literature on 64bit java. It says 64 bit jvm could
be slower than 32 jvm because all paths are larger (pointers etc). ?S
o
if application java code is not taking advantage of 64 bit
architecture, things could be slower.
As Lew says, "could be" isn't a useful predictor of what will happen.
If you care about performance, you need to test all relevant scenarios
and find out which one actually performs best.
Larger pointers can slow things down, because of increased data size,
but can speed things up too, because of other factors (e.g. more
efficient use of instructions). ?The only way to find out how these
competing factors resolve is to test.
My question is:
If I just install java 32 bit jvm (JDK 1.6 for Windows) on 64 bit os,
will it let me take advantage of additional memory (up to 4GB instead
of 8GB)? Do I need to make java.exe /LARGEADDRESSAWARE flag set or
32bit java.exe by itself can access up to 4GB memory, I am on 64 bit
Windows OS.
I don't actually know off the top of my head whether the 32-bit JVM is
marked as /LARGEADDRESSAWARE. ?But is no more difficult for you to find
out this information than any of the rest of us. ?You just need to dump
out the PE information (see, for example, the Visual Studio DUMPBIN.EXE
utility).
Pete
Pete:
Thanks. I have read many confusing articles on this subject googling,
but I am unable to see any dieference in java.exe after running:
editbin.exe /LARGEADDRESSAWARE .\java.exe
Do that at your own risk.
It is not safe to arbitrarily set /LARGEADDRESSAWARE on executables you
did not write. LARGEADDRESSAWARE is a way for the programer to inform
the compiler, linker, and loader that the program does not make certain
classes of assumptions about pointers; *only* the programmer can make
that call, not end users.
If you set the flag on a program you did not write, and that program
*does* make the kinds of assumptions that are invalidated by large
pointers, then you just broke the program. Since Sun didn't see fit to
set that flag, you cannot assume the 32-bit VM doesn't make
small-pointer assumptions.
See <http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx>
and the related articles for a more thorough explanation and
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5061380> for an RFE
to get it added to the VM. There are also a few threads about it on the
OpenJDK dev lists -- google around.
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. So, no 3GB heaps on 32-bit Windows Hotspot VMs
even if the VM becomes /LARGEADDRESSAWARE.
(In theory there's nothing preventing a 32-bit VM from having a 2 TB
heap, implemented using paging. However, it's a lot cheaper and easier
to buy 64-bit hardware and enjoy a massive, OS-managed address space
than it is to write your own memory manager.)
-o