Comments on: 32-bit or 64-bit JVM? How about a Hybrid?

By: Ismael Juma

Ismael Juma — Thu, 11 Feb 2010 20:51:21 +0000

No problem and good luck. :)

By: fpc

fpc — Thu, 11 Feb 2010 20:45:52 +0000

Thanks very much Ismael. I’ll give that a shot. :)

By: Ismael Juma

Ismael Juma — Thu, 11 Feb 2010 20:44:19 +0000

Hi fpc,

You need Java 6 Update 14 or newer (I recommend Java 6 Update 18 if you want to use this feature as it contains an improved version of it).

Best,
Ismael

By: fpc

fpc — Thu, 11 Feb 2010 20:41:43 +0000

Hi,

I tried adding “-XX:+UseCompressedOops” to our java options for running tomcat and I’m getting this error:
Unrecognized VM option ‘+UseCompressedOops’
Could not create the Java virtual machine.

We’re using java 1.6.0_12 and it is a 64 bit server (and 64 bit jvm). What might be causing this?
java -version
————-
java version “1.6.0_12″
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
————-

Thanks in advance,
fpc

By: Kari’s World » Blog Archive » Oops, I did it again….

Kari’s World » Blog Archive » Oops, I did it again…. — Wed, 27 Jan 2010 18:27:33 +0000

[...] 32-bit or 64-bit JVM? How about a Hybrid? Load unsigned and better Compressed [...]

By: Knowtu » links for 2009-10-27

Knowtu » links for 2009-10-27 — Wed, 28 Oct 2009 01:05:50 +0000

[...] 32-bit or 64-bit JVM? How about a Hybrid? « Ismael Juma (tags: java performance 64) [...]

By: New JVM options and Scala iteration performance « Ismael Juma

New JVM options and Scala iteration performance « Ismael Juma — Mon, 26 Oct 2009 14:00:53 +0000

[...] on Q4, 2009 and it includes HotSpot 16. Even though JDK 6 Update 14 (HotSpot 14) introduced compressed references and scalar replacement, HotSpot 16 includes improved compressed references and many crucial fixes [...]

By: Sunil

Sunil — Thu, 30 Jul 2009 17:59:22 +0000

Juma,
We are using solaris10 32 bit JVM on our production servers with Sun one app server. As we are constatnly getting out of memory – heap error, I am planning to increase the heap size to 4G for JVM options. Current heap size is 2G and we have 8G memory available.

By: Ismael Juma

Ismael Juma — Wed, 08 Apr 2009 18:59:34 +0000

No problem Alain, glad to help.

By: Alain Picard

Alain Picard — Wed, 08 Apr 2009 18:30:25 +0000

I really thought I was. Thanks for steering me in the right direction

Alain

By: Ismael Juma

Ismael Juma — Wed, 08 Apr 2009 08:35:12 +0000

Alain, are you using a 64-bit JVM? I think yours is a 32-bit JVM and that is why it doesn’t work.

Best,
Ismael

By: Alain Picard

Alain Picard — Wed, 08 Apr 2009 00:43:19 +0000

C:\Program Files (x86)\Java\jdk1.6.0_14\bin>java -version
java version “1.6.0_14-ea”
Java(TM) SE Runtime Environment (build 1.6.0_14-ea-b04)
Java HotSpot(TM) Client VM (build 14.0-b13, mixed mode, sharing)

By: Ismael Juma

Ismael Juma — Wed, 08 Apr 2009 00:00:22 +0000

Hi Alain, that is strange. What does java -version say?

By: Alain Picard

Alain Picard — Tue, 07 Apr 2009 23:47:39 +0000

I just downloaded the jdk update 14 early access and it doesn’t accept the CompressedOops option.

C:\Program Files (x86)\Java\jdk1.6.0_14\bin>java -XX:MaxPermSize=256m -Xms3400m
-Xmx3400m -server -XX:+UseConcMarkSweepGC -XX:+UseCompressedOops
Unrecognized VM option ‘+UseCompressedOops’

what is happening here, help please.

Alain

By: Cliff Click

Cliff Click — Fri, 03 Apr 2009 15:08:10 +0000

fyi, the Azul JVM virtualizes… so a “32-bit” JVM will run as a 64-bit JVM on the backend. We do all the usual pointer munging when you have to cross the barrier (eg. for JNI calls).

Cliff

By: Load unsigned and better Compressed Oops « Ismael Juma

Load unsigned and better Compressed Oops « Ismael Juma — Fri, 03 Apr 2009 09:46:50 +0000

[...] end result is that 64-bit now surpasses 32-bit performance in more situations. See my entry about Compressed Oops if you don’t know what I’m talking about. [...]

By: Ismael Juma

Ismael Juma — Mon, 16 Mar 2009 19:03:46 +0000

Is it possible that you were using the -client JIT while using 32-bit Windows? The -server JIT has a tendency to use all the memory you give it for tasks that allocate a lot. What happens if you increase the size of the data set? Does it OOM or does it process it fine?

Ismael

By: Joe Faith

Joe Faith — Mon, 16 Mar 2009 12:36:16 +0000

Thanks for the swift response.

I’ve included the output from jconsole below — and yes it is picking up the arguments.
As you can see, its currently using >3GB heap to do this job, whereas a 32bit windows xp machine was handling data sets three times this size in 1.6GB!

I’m tempted to try switching to linux, but would prefer to avoid the hassle if its something stupid I’m doing

I’ve tried JDK 6.12, and both JDK 6 Update 14 and JDK6u6p with compressed OOPS and the all seemed to perform similarly

(BTW I’m using concurrent mark sweep GC; but the ParNew GC is still running. Is there any way of disabling the latter)

thanks again for your advice

VM Summary
Monday, 16 March 2009 12:27:42 o’clock GMT

Connection name:
pid: 848 tpp.weka.AttributeSelectionExperimentFiltered
Virtual Machine:
Java HotSpot(TM) 64-Bit Server VM version 14.0-b12
Vendor:
Sun Microsystems Inc.
Name:
848@c09000117
Uptime:
8 minutes
Process CPU time:
4 minutes
JIT compiler:
HotSpot 64-Bit Server Compiler
Total compile time:
13.044 seconds

Live threads:
16
Peak:
17
Daemon threads:
15
Total threads started:
40
Current classes loaded:
2,698
Total classes loaded:
2,728
Total classes unloaded:
30

Current heap size:
3,265,537 kbytes
Maximum heap size:
3,477,376 kbytes
Committed memory:
3,477,376 kbytes
Pending finalization:
0 objects
Garbage collector:
Name = ‘ParNew’, Collections = 1,393, Total time spent = Unavailable
Garbage collector:
Name = ‘ConcurrentMarkSweep’, Collections = 3, Total time spent = 3.261 seconds

Operating System:
Windows XP 5.2
Architecture:
amd64
Number of processors:
2
Committed virtual memory:
3,621,828 kbytes
Total physical memory:
3,914,768 kbytes
Free physical memory:
112,560 kbytes
Total swap space:
106,064,464 kbytes
Free swap space:
101,846,808 kbytes

VM arguments:
-XX:+UseConcMarkSweepGC -Xms3400m -XX:MaxPermSize=256m -XX:+UseCompressedOops -Xmx3400m
Class path:
.
Library path:
C:\WINDOWS\system32;.;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Boot class path:
C:\Program Files\Java\jre6\lib\resources.jar;C:\Program Files\Java\jre6\lib\rt.jar;C:\Program Files\Java\jre6\lib\sunrsasign.jar;C:\Program Files\Java\jre6\lib\jsse.jar;C:\Program Files\Java\jre6\lib\jce.jar;C:\Program Files\Java\jre6\lib\charsets.jar;C:\Program Files\Java\jre6\classes

By: Ismael Juma

Ismael Juma — Mon, 16 Mar 2009 11:57:38 +0000

Hi Joe,

That sounds very strange. I haven’t used Windows in a while, so I can’t say if it’s a Windows problem, but it seems unlikely.

Have you verified that your JVM settings are being picked up? You can use jconsole to verify this while the process is running.

Ismael

By: Joe Faith

Joe Faith — Mon, 16 Mar 2009 11:32:44 +0000

I’ve been trying to process some large data sets using the weka data mining package (www.cs.waikato.ac.nz/ml/weka/). They were too big for Java on windows XP 32-bit so I moved to a windows XP 64-bit machine, but the memory consumption has been appalling — its using approximately 6 times the memory for the same amount of raw data! (On the 64 bit machine I can only process data sets one third the size the 32bit machine could handle despite having twice the addressable heap!)

I’ve tried using JDK 6 update 14 and compressed OOPS, but it didn’t seem to make any difference at all. I’d be grateful for any thoughts/advice. Is it a windows problem?

current JVM settings:
-XX:MaxPermSize=256m -Xms3400m -Xmx3400m -server -XX:+UseConcMarkSweepGC -XX:+UseCompressedOops