3 Replies Latest reply: Oct 25, 2010 6:04 AM by 660238 RSS

    OutOfMemoryErrors on 64-bit JVM

    806713
      I have just got a new laptop which has taken me from 32-bit Windows XP on Intel dual core to 64-bit Windows 7 on 4-processor Intel i5. So I installed 64-bit JDK from Oracle. I found that my image processing application, which had run happily with a max heap (-Xmx) of 1GB in 2GB of physical RAM kept crashing with OutOfMemoryErrors on the new platform whatever heap size I tried (in 4GB of RAM). Googling for a solution I found that lots of people have had the same problem, with various applications. They tried varying heap sizes but concluded that 64-bit JVMs must require too much memory (even though some of them had tens of GB for the heap). Several people advise reverting to 32-bit Java to solve the problem but I could find no other solution.
      I could not believe that. Eventually I found a relevant Sun (Oracle) page: http://download.oracle.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html and after reading that I changed my start-up command to include -XX:+UseSerialGC.That solves my problem completely. But my question is, is there a better way? Should I be using the parallel GC but with some other settings?
      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.
        • 1. Re: OutOfMemoryErrors on 64-bit JVM
          jschellSomeoneStoleMyAlias
          grelf wrote:
          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.
          I would like to see at least one link for that first assertion.

          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.
          • 2. Re: OutOfMemoryErrors on 64-bit JVM
            ++sja
            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.)
            • 3. Re: OutOfMemoryErrors on 64-bit JVM
              660238
              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.