Skip to main content

Running an application under 64Bit JVM

6 replies [Last post]
towser
Offline
Joined: 2008-07-17
Points: 0

Hi - I've a 3rd party application that we've deployed and operated in a 32Bit JVM.

We're looking to move to a 64Bit JVM primarily because our hardware platform / OS / App Server mix mandates the use of 64Bit JVM.

If I deploy the 3rd party application into a 64Bit JVM are there any gotchas I need to consider - performance or otherwise? I realise there's probably an increased GC overhead given larger heap space etc etc.....anything else?

Is it safe to assume that functionally the application will continue to operate as before and that I only need to focus on tuning the JVM for optimal performance??

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
briand
Offline
Joined: 2005-07-11
Points: 0

Generally speaking, a 64-bit OS does not mandate the use of a 64-bit JVM.
Most OS's allow you to run 32-bit processes on 64-bit OS's. On linux, though,
this may require the installation of additional packages.

The primary reason for running a 64-bit JVM is that the process address space
of a 32-bit process isn't large enough for your desired Java Heap Size. For most
32-bit process virtual address spaces, you can get about 3.5GB of java heap. On
windows, though, the limit is more like 1.5GB (as windows uses 2GB of the process
virtual address space to run the kernel when the process traps into the kernel).

Other things your process does could impact that maximum heap size. For example,
if you use Mapped Byte Buffer objects or have native threads that allocate C-heap space,
those things also need virtual address space. Each additional thread the application
runs also requires virtual address space outside the Java heap. Depending on how
many of these things are used, you may not be able to achieve the 'maximum' heap
sizes I mentioned above.

A more obscure reason to run in a 64-bit address space is that you may have
64-bit native libraries that are not available as 32-bit native libraries. A 32-bit process
can't load 64-bit libraries and vice-versa.

Running in a 64-bit process will generally reduce your application's performance,
as each memory reference (both object references and instruction addresses) are
now 64-bit quantities. This generally has the effect of cutting your instruction and data
cache sizes in half, thus reducing the cache hit ratios and reducing performance. The
effect is a bit less pronounced with x64 hardware, as these chips provide additional
hardware registers that the JIT can make use of to improve performance elsewhere.
However, for many applications, the large heap sizes that can be used with 64-bit
JVMs can greatly improve the scalability of the application, which can be seen as
a performance improvement (depending on your definition of performance).

We are working on technologies to reduce this cache effect with 64-bit address spaces
by using base+offset type references, but these are not generally available at this
time.

Finally, a Java application that contains no non-JDK native libraries should
run identically in a 64-bit JVM as it does in a 32-bit JVM. The performance

HTH
Brian

towser
Offline
Joined: 2008-07-17
Points: 0

Brian - thanks for this, you make mention of the fact that as long as the application has been built using JDK native libraries the point that it's running within a 64Bit or 32Bit JVM should make no difference.

Is this because the libraries should be consistent and tested across both JVMs by the JVM "vendor" in my case case IBM for Websphere, whereas non-core libraries don't have the same gaurantee?

Regards

Doug

briand
Offline
Joined: 2005-07-11
Points: 0

Basically, yes. The native libraries shipped with the JDK already are compiled
to be loaded into the corresponding JDK data model (32-bit or 64-bit) and have
been tested accordingly. Third party native libraries, whether provided by a
vendor or home grown, need to be similarly built and tested in order to run
within a 64-bit JVM.

Some third party software vendors won't support running their application on
non-tested JVMs. You could run across a 100% pure Java application from a
vendor that will technically run unmodified without issue on a 64-bit JVM, but
that vendor might not be willing to support the application on the 64-bit JVM
because they have not explicitly tested that configuration. You'd need to work
with the 3rd party vendor to resolve that issue.

Brian

towser
Offline
Joined: 2008-07-17
Points: 0

That's exactly the position I'm in. The vendor is a bit reluctant to say they'll support a 64Bit JVM, I'm trying to understand the challenges.

So you've helped me down the road there, fundamentally it sounds to me that if either of the following statements are true :

1) The vendor is using non-JDK native libraries as part of the application ( i.e. precompiled 32bit libraries ) then there's an issue that has to be overcome.

2) The vendor uses non-Java code compiled to run on a 32Bit as part of the application and calls via JNI then that code will also have to be compiled to run on a 64Bit platform.

vgobiraj
Offline
Joined: 2003-06-27
Points: 0

Any idea what will be the impact for the heap size when moving from 32 bit to 64 bit.

For e.g. If we were using 1GB heap in 32 bit OS do we need to increase it while we move to 64 bit to retain the same memory for the application.

Thanks

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> For e.g. If we were using 1GB heap in 32 bit OS do we
> need to increase it while we move to 64 bit to retain
> the same memory for the application.

Yes, however how much depends on the data your application holds in heap.
For typical buissness apps its about 10-30%, you could easily construct cases where you need 70% more too.

So, yes in any case you need more memory - how much depends in the app, but typically between 10% and 30%.

lg Clemens