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: Robert Klemme on 27 Dec 2009 16:41 On 12/27/2009 05:25 PM, Arne Vajhøj wrote: > -Xmx8g may be needed if the default is below 8 GB (which it > most likely is). Note also that "more memory" not necessarily equals "faster". In fact it can be slower depending on application type (i.e. object allocation patterns) and runtime because of GC effects and of course paging if you do not have physical memory of that size. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Owen Jacobson on 27 Dec 2009 16:54 On 2009-12-27 15:11:36 -0500, zigzagdna <zigzagdna(a)yahoo.com> said: > 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). �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
From: zigzagdna on 27 Dec 2009 17:17 On Dec 27, 3:27 pm, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote: > 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 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
From: zigzagdna on 27 Dec 2009 17:50 On Dec 27, 4:54 pm, Owen Jacobson <angrybald...(a)gmail.com> wrote: > On 2009-12-27 15:11:36 -0500, zigzagdna <zigzag...(a)yahoo.com> said: > > > > > > > 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). 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- 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.
From: Mike Schilling on 27 Dec 2009 18:28
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. > than 32bit JVM on 64bit OS unless one is > taking advantage of larger physical memory on the server. |