Home/ Questions/Q 6387735
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T03:11:23+00:00

I asked the same question in a different way and the question was closed

  • 0

I asked the same question in a different way and the question was closed : https://stackoverflow.com/questions/7231460/java-64-bit-or-32-bit
This is my 2nd try at getting an objective answer(s).

We were contemplating moving our product to 64-bit Java for those customers who are pushing the boundaries of the 32-bit server JVM on Solaris (SPARC) and Linux (RHEL 5.x). Our director asked “some years ago, 64-bit wasn’t quite there. How about now?”

  1. For those customers not pushing the 4 GB boundary, will using 64-bit JVM have adverse effects in terms of performance? If yes, how much? We create a lot of objects. (we don’t want to support 32-bit and 64-bit JVMs at the same time. It’s a either or situation, preferably).

  2. For those pushing the 4 GB boundary, can we expect the JVM to be as stable as the 32-bit one?

    • Will performance be an issue? If yes, how much? we create a lot of objects.
    • What GC tuning techniques are new ?
    • Profilers: are they quite there for profiling 64-bit JVM apps?

UPDATE : To those commenters and those who closed my earlier question, I believe I NOW understand your angst. At the same time, I believe some of you made some (untrue) assumptions that I was lazy or a suit who has no clue. I’ll post my findings after my investigations. Thanks to all those who gave me real pointers.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We were contemplating moving our product to 64-bit java for those customers who are pushing the boundaries of the 32- bit server JVM on Solaris(SPARC) and Linux(RHEL 5.x). Our director asked “some years ago, 64-bit wasn’t quite there. How about now ?”

    Sun have been doing 64-bit for much longer than Windows. Solaris 2.5 (1995 the same year Windows 95 was released) wasn’t as reliable in 64-bit as it could have been. Many people still on SunOS (32-bit) didn’t see the point and few machine has enough memory to matter. Solaris 2.6 (1997) saw the first significant migration to the 64-bit platform. I didn’t use Java seriously until 1999 (on Solaris) and at that point 64-bit what already established in my mind.

    1) For those customers not pushing the 4 GB boundary, will using 64-bit JVM have adverse effects in terms of performance ? if yes, how much ?

    The 64-bit JVM has registers twice the size and twice as many. If you use long alot you can see a dramatic improvement, however for typical applications the difference is 5-10% either way.

    we create a lot of objects.

    IMHO Performance hasn’t been much of an issue for you if this isn’t recognised as a problem for you. Use any profiler and there are two reports CPU and Memory usage. Often examining the memory profile makes more of a performance difference. (See below)

    (we preferably don’t want to support 32-bit and 64-bit JVMs at the same time. It’s a either or situation, preferably)
    Can’t say there is much difference. What do you imagine is the overhead of supporting each. The code is exactly the same, from your point of view it might increase testing slightly. It not much different to supporting two versions of Java 6.

    2) For those pushing the 4 GB boundary, can we expect the JVM to be as stable as 32-bit ?

    Having used the 64-bit version since 1999 I can’t remember an occasion where using the 32-bit would have made things better (only worse due to limited memory)

    will performance be an issue ? if yes, how much ? we create a lot of objects.

    If performance is an issue, discard less objects.

    what GC tuning techniques are new ?

    You can set the maximum memory size higher. That’s about it. As long as you are below 32 GB there won’t be a noticable increase in memory usage as it uses 32-bit references.

    One thing I do is set the Eden size to 8 GB for a new application and reduce it if its not needed. This can dramatically reduce GC times. (To as low as once per day 😉 This wouldn’t be an option with a 32-bit JVM.

    profilers : are they quite there for profiling 64-bit JVM apps ?

    The VisualVM is pure Java and AFAIK works exactly the same. YourKit uses a native library and might need to ensure you are using the right version (it normally sets this up for you, but if you mess with your environment you might need to know there are two versions of the agent)

    If you are worried about performance, don’t create so many objects. You might be surprised how much slower creating objects freely makes in real world applications. It can slow an application by 2x to 10x or more. When I optimise code the first thing I do is reduce the discarding of object and I expect at least a three fold performance improvement.

    By comparison using 64-bit vs 32-bit is likely to be 5%-10% difference. It can be faster or slower and both are just as likely. In terms of bloating your memory, use the latest JVMs and that is unlikely to be noticeable. This is because the 64-bit JVM uses 32-bit references by default when you use less than 32 GB of memory. The header overhead is still slightly higher but objects are not much bigger in 64-bit when -XX:+UseCompressedOops is on (the default for the latest releases).

    Java: All about 64-bit programming

    Test the size of common objects using 32-bit vs 64-bit JVMs Java: Getting the size of an Object

    A extreme example of doing the same thing creating lots of objects and reflection vs not creating any and using dynamically generated code. 1000x performance improvement. Avoiding Java Serialization to increase performance

    Using heap less memory can massively reduce your GC times. Collections Library for millions of elements

    Using heap less memory can allow your application to use much more memory instead of passing data to another application Should server applications limit themselves to 4 GB?

    • 0