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: Lew on 27 Dec 2009 12:12 zigzagdna wrote: > 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
From: zigzagdna on 27 Dec 2009 12:34 On Dec 27, 12:12 pm, Lew <no...(a)lewscanon.com> wrote: > zigzagdna wrote: > > 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 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.
From: Peter Duniho on 27 Dec 2009 14:31 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). So > 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
From: zigzagdna on 27 Dec 2009 15:11 On Dec 27, 2:31 pm, Peter Duniho <NpOeStPe...(a)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). So > > 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 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.
From: Peter Duniho on 27 Dec 2009 15:27
zigzagdna wrote: > [...] > 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 |