compilattion of java for 64 bit

[zigzagdna]

I have jdk 5.0 and jdk 6.0 installed on my HP UNIX 11i. I see java
has options: -d32 and
-d64. But I do not see coresponding options in javac, why?

If I want to run 64 bit java to take advantage of larger than 4GB
heaps, do I need to compile my java code using some 64 bit option. It
is naive question? Or any .jar files will start taking advnatage of 64
bit java, if I start my application using java -d64.


THANKS A LOT,

 

[Frank Langelage]

I have jdk 5.0 and jdk 6.0 installed on my HP UNIX 11i. I see java
has options: -d32 and
-d64. But I do not see corresponding options in javac, why?

If I want to run 64 bit java to take advantage of larger than 4GB
heaps, do I need to compile my java code using some 64 bit option. It
is naive question? Or any .jar files will start taking advantage of 64
bit java, if I start my application using java -d64.

THANKS A LOT,

The source code and byte code is independent of the pointer size or
memory size you wan't to use at runtime.
So no need for javac to have the size option.
You can use the same class (jar-) files for both models.

The native code of the JRE and the JDK have to be compiled and available
in 32- and 64-bit if you want to use both.

 

[zigzagdna]

The source code and byte code is independent of the pointer size or
memory size you wan't to use at runtime.
So no need for javac to have the size option.
You can use the same class (jar-) files for both models.

The native code of the JRE and the JDK have to be compiled and available
in 32- and 64-bit if you want to use both.

Question on WIndows Platform:
Let us I download jdk 1.6 for Windows X-64. Then my jvm is 64 bit. I
then have to specify java -d64 to use 64 bit memory capability. My
existing third party jar files, Apacake tomcat etc will automatically
start taking advantage of more memory. Do I have to set -Xmx option.
i.e.,
java -d64 -XmX 8024M so haeap emory can grow to 8GB.

 

[Arne Vajhøj]

Question on WIndows Platform:
Let us I download jdk 1.6 for Windows X-64. Then my jvm is 64 bit. I
then have to specify java -d64 to use 64 bit memory capability.

Unless it is default.

> My
existing third party jar files, Apacake tomcat etc will automatically
start taking advantage of more memory.
Yes.

Do I have to set -Xmx option.
i.e.,
java -d64 -XmX 8024M so haeap emory can grow to 8GB.

-Xmx8g may be needed if the default is below 8 GB (which it
most likely is).

Arne

 

[zigzagdna]

Unless it is default.

 >                                                                  My


-Xmx8g may be needed if the default is below 8 GB (which it
most likely is).

Arne- Hide quoted text -

- Show quoted tex

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). So
if application java code is not taking advantage of 64 bit
architecture, things could be slower.

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.

 

[Lew]

Unless it is default.

-Xmx8g may be needed if the default is below 8 GB (which it
most likely is).

<http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html>

<http://java.sun.com/javase/6/docs/technotes/tools/index.html#basic>
<http://java.sun.com/javase/6/docs/technotes/tools/windows/javac.html>
<http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html>

From the command line:
java -?

 

[Lew]

I am reading some literature on 64bit java [sic]. It says 64 bit jvm could
be slower than 32 jvm because all paths are larger (pointers etc). So
if application java [sic] code is not taking advantage of 64 bit
architecture, things could be slower.

-XX:+UseCompressedOops

"could be" isn't "will be".

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.

Peter Duniho answered this question in your thread "Running 32 bit java,
tomcat etc on 64bit WIndows OS" about eleven hours before you reposted it here.

 

[zigzagdna]

I am reading some literature on 64bit java [sic]. It says 64 bit jvm could
be slower than 32 jvm because all paths are larger (pointers etc).  So
if application java [sic] code is not taking advantage of 64 bit
architecture, things could be slower.

-XX:+UseCompressedOops

"could be" isn't "will be".

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.

Peter Duniho answered this question in your thread "Running 32 bit java,
tomcat etc on 64bit WIndows OS" about eleven hours before you reposted it here.

Lew:
Thanks a lot for your answers. Peter answered another question, but
not what I am asking here.
Is java.exe 32 bit by itself /LARGEADDRESSAWARE, or I have to
explictly set it using some Visual
Studio tool.

If it is not possible to set LARGEADDRESSAWARE for java.exe, then
there is no advantage to going to 64bit os when runing 32 bit jvm as
for as I can see.

 

[zigzagdna]

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.


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

When I run dumpbin.exe .\java.exe
I see no indication that any flag was set in header

Dump of file .\java.exe

File Type: EXECUTABLE IMAGE

Summary

4000 .data
1000 .rdata
1000 .rsrc
6000 .text

I tried both with jdk 1.5 adn 1.6.

 

[Owen Jacobson]

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

 

[zigzagdna]

[...]
When I run dumpbin.exe .\java.exe
I see no indication that any flag was set in header

Are you using the /headers option?

All that said, it seems to me that a more useful test is to write a
simple Java program and see how large you can make its heap (using the
appropriate command line settings of course, you can do this part of the
test with any Java program), and how much memory you can allocate in the
program.

Pete

Pete:
Thanks so much, you have been so helpfile. I had fofrggen /headers
when running dumpbin.
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.
Based on my reading on google, I have to also do it for all the .dll
in bin directory.


Prem

 

[zigzagdna]

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- Hide quoted text -

- Show quoted text -

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.
So one should be able to get 2GB heap (instaed of 1 to 1.6G heap in 32
GB) without /LARGEADDRESSAWARE.

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.

 

[Mike Schilling]

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.

 

[Kevin McMurtrie]

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.

 

[Roedy Green]

I have jdk 5.0 and jdk 6.0 installed on my HP UNIX 11i. I see java
has options: -d32 and
-d64. But I do not see coresponding options in javac, why?

The class files for 32 bit and 64 bit are identical. You can run the
same class file as 32 bit or 64 bit. When you use 64 bit, you have
more address space at your disposal.

 

[Lew]

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?

 

[Owen Jacobson]

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

 

[alexandre_paterson]

I am reading some literature on 64bit java [sic]. It says 64 bit jvm could
be slower than 32 jvm because all paths are larger (pointers etc).  So
if application java [sic] code is not taking advantage of 64 bit
architecture, things could be slower.

-XX:+UseCompressedOops

OP's concern as I read his post was about
speed, not memory usage.

I think we are conflating two very different issues
here Lew aren't we!?

- memory bloat without compressed pointers
for applications that keep lots of references
in memory

- speed: which may or may not be faster by using 64 bits
pointers on 64 bits CPUs

And altough the two are related the answer is *much*
more complicated than your usual "one-line-I-know-it-all"
answers.

In that case one could even say you're misleading, if not
downright off the mark and simply, well... wrong.

I recently read a fascinating article written by dudes
much smarter than me who were surprised to see that the
64 bit version of their algo, despite a higher memory
usage, was faster (even tough they needn't 64 bit).

It wasn't Java but still: that was *without* any
encoding/decoding and the 64 bit version was already
faster.

Using UseCompressedOops there's pointer encoding/decoding
going on (it's document, Google is your friend Lew) and
it is documented that, albeit low, there's still a cost to
it. So in addition to the fact that 64 bit with 32 bit
waste may already be faster in itself on 64 bit cpu, your
adding compressed pointer encoding/decoding to the issue.

Just slightly missing OP's concern about speed I think...

It's people who have memory issue, not speed issue (the
two being not always related), who want to look into
compressed pointers.

This is a subject much more complex than:

"-XX:+UseCompressedOops"

especially if the concern is about speed, not memory.

lol ?

But as usual your one liner was enlightening right?

Grammar naziness and JLS-worshipping can be sent
to /dev/null.

 

[John B. Matthews]

Grammar naziness

As a nazi nazi, I feel compelled to criticize your inappropriate comparison to the Nazis by mentioning Godwin's Law:

<http://en.wikipedia.org/wiki/Godwin's_law>

but I am too late:

<http://groups.google.com/group/comp.lang.java.programmer/msg/92ebfa54cf35f3cb>

I probably need to consult a nazi nazi nazi for some kind of ruling.

 

[Tom Anderson]

Read it more carefully: *may* run slightly slower.

Without compressed OOPs, *will probably* run moderately slower.

With compressed OOPs, *will probably not* run noticeably slower.

tom