Skip to main content

a jvm with an 8GB heap size

8 replies [Last post]
philippelocatelli
Offline
Joined: 2007-05-24
Points: 0

we are using java 1.5 64bit
our application needs a heap size of about 8GB.

has somebody an experience with such a heap size on one jvm?
- is the system still stable?
- should we better split the application on several jvm's

thanks for you support
philippe

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24
Points: 0

Hmm, why?

Why would the 64-bit JVM be any slower than the 32-bit one? Or did you mean the slowdown only occurs with heaps bigger than 4GB? Even if the latter is the case, can you please explain why a slowdown occurs? I'm curious :)

Thank you,
Gili

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

> Why would the 64-bit JVM be any slower than the
> 32-bit one? Or did you mean the slowdown only occurs
> with heaps bigger than 4GB? Even if the latter is the
> case, can you please explain why a slowdown occurs?

The slowdown occurs because Pointers/References are now 8byte instead of just 4byte large.
Any because Java is heavily OO'ed a lot of references are used/stored, which means more memory consumption -> more IO and work for the CPU. Don't know wether the per-object-overhead also grows but I guess since I read hotspot's object-header is 2 words, its now 16byte instead of just 8byte on a 32-bit machine.

However for integer-stuff (encryption, ...) you'll see increased performance because of the additional registers available.

lg Clemens

philippelocatelli
Offline
Joined: 2007-05-24
Points: 0

thanks linuxhippy,

may i ask you on which kind of platform you are running this jvm?
- CPU
- OS

we are on Opteron 64bit + Suse linux enterprise server 9 64bit

thanks
philippe

smoov
Offline
Joined: 2007-05-01
Points: 0

I've seen 8g heaps in some of the published results on http://www.spec.org/, under Java Client/Server jAppServer2004. Even though running a benchmark may not be related to running your application, you can see what hardware, OS and other settings they used to get there.

sdo
Offline
Joined: 2005-05-23
Points: 0

Yes, but be aware that you will lose a fair amount of performance with a the 64-bit JVM (needed for anything over a 4GB heap). For SPECjAppSevrver, eg, no one actually used heaps that large on their appserver, where the performance mattered: they used it on the load generators and emulators, where large numbers of threads (and corresponding memory use) was what mattered.

The 64-bit JVM is quite robust and stable, but (since this is the performance forum :-) you have to consider whether taking the performance hit is worth the ability to use the extra heap space.

smoov
Offline
Joined: 2007-05-01
Points: 0

sdo,

How would you characterize the performance hit one might expect by simply switching from a 32-bit JVM to a 64-bit JVM? Say for instance, someone adds the -d64 JVM option to an application with known performance metrics, where would they notice the hit?

sdo
Offline
Joined: 2005-05-23
Points: 0

It will depend on the application, of course -- on appservers, I've seen total throughput decrease anywhere from 5% to 22%. The thing that makes it slower is that 64-bit pointers are used instead of 32-bit pointers -- so GC takes longer to compact the heap, and other operations can take longer too. On the other hand, arithmetic operations will take the same amount of time, and algorithms that can take advantage of a larger data set (perhaps a cached dataset from disk or a database) will run faster if they don't have to spend as much time refreshing that data.

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

Hello,

yes we've some boxes running with such a large heap. It works stable and reliable - the only thing which needs attention are gc-pauses when a full gc occurs.
So it depends what type of software you intend to run on that box - software which has e.g. a maximum repsonse time of 5s is maybe not a good idea ;)

Make sure you use the latest java-1.5 update release (there have been some improvements over time) or better java(1.)6. Use Paralell and ParalellOldGC and size your newgeneration large "enough" but not "too large" ;)

Good luck, lg Clemens

btw. it would be great if you could let "us" know wether/how good it works ;)