This content has been marked as final. Show 3 replies
grelf wrote:I would like to see at least one link for that first assertion.
It seems that a lot of people out there are under the false impression that 64-bit Java is no good because there is a problem with heap size, when the real issue is the parallel garbage collector but it gives inappropriate failure messages.
Certainly people have been running the 64 bit VM successfully for years.
Do you have any other command line options?
whatever heap size I tried (in 4GB of RAM)The application is a GUI and without attempting to process anything it would not start?
Or it processes files and you gave it exactly the same set of files for each test?
There are at least some failure paths there that suggest a problem with the application not the VM.
Presumably you are not using the /3GB in windows.
64-bit programs have a fundamental feature: pointers take eight bytes of memory, instead of the four bytes in a 32-bit program. That is what 64-bit program means: bigger potential address space, with the cost of bigger pointers. If you have a program that has lots of pointers, its memory usage is necessarily increased.
Intel's 64-bit architecture gives extra registers and instructions, making generated code potentially faster. But because pointers are fatter, they occupy more cache memory, and moving a bunch of pointers from memory to cache takes longer. An article in Dr. Dobb's (RIP) once described an application whose speed was pretty much the same in either 32 or 64 bit mode, presumably because what an extra register giveth, a fat pointer taketh away.
If your CPU can execute both 32-bit and 64-bit programs, use 64-bit programs only if you need to use more than 4 GB of memory, or benchmarking otherwise shows it improves speed. 64-bit not an automatic improvement.
(If you want to experiment: try the G1 collector in the latest Java 6 version. It's still considered experimental, so disclaimers about using it in a production setting apply. Use "java -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC" to get G1, and google for more info.)
Thanks for the info. I am experiencing similar problems. I haven't investigated this thoroughly, but using -XX:+UseCompressedOops with -XX:+UseParallelGC gave large fluctuations in memory usage and eventually crashed my system (Vista checkdisk started to run). Using -XX:+UseSerialGC seems to be more stable.