2

I created test application (with Sheduler inside that runs every 20ms, there are reads/writes to DB) and deployed it on Glassfish server on two different PC. Both have same (copy from one PC to another) Glassfish (both have also latest JAVA version) server with following flags: -XX:+DisableExplicitGC, XX:MaxGCPauseMillis=200, -Xmx512m, -Xms512m, -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC, -server...

First PC has 8GB of RAM, i5 CPU (2.5 GHz) with WIN 8.1 64bit OS.

Here is the graphical presentation of GC log of first PC (after 30 hours): enter image description here

As you can see GC Peformance is around 12000 MB/s, throughput is 99,93%, minor GC pauses are around 20ms long and they occur every 30 seconds. There was na major GC at this time (but it happened 8 hours later). In the first 30 hours old generation increased from 90 MB to 160 MB.

The second PC has 1GB of RAM, Athlon 64 X2 (dual core) CPU AND WIN XP 32bit. Here is the graphical presentation of GC log of second PC (after 30 hours): enter image description here

As you can see GC Peformance is around 4000 MB/s, throughput is 99,91%, minor GC pauses are around 100ms long and they occur every 50 seconds. There was na major GC at this time (it still didn't happen after 4 days). In the first 30 hours old generation increased from around 70 MB to 75 MB.

My question here is: why is promotion to old generation in second case much smaller than in the first case? This mean that major GC won't be triggered quite some time (maybe never) when major GC in first case was triggered after 40hours. Application is doing same things in both cases so I don't get it why JVM is functioning so much differently with same flags. I don't know what are benefits in the first case (more object promotion to old generation) if that means that major GC have to occur when in the second case major GC won't have to occur. What is benefit of promoting from survivor space to old generation if application on both servers is performed at the same speed (write to DB every 20ms and then some read from same DB tanle). Also minor GC in the second case are more rarely (50 seconds) than in the first case (30 seconds). I would expect than better PC would have much better results but now I don't even know which one is better... Only major advantage of first case is higher GC Performance speed so minor GC are done faster. Thank you all for clarify why it is done so as it is.

Community
  • 1
  • 1
user4341206
  • 647
  • 1
  • 7
  • 26
  • What are the exact versions of Java on each? – Chris Dennett Jun 08 '15 at 15:43
  • 1
    On both is the latest version of JAVA (8u45), on first is 64bit and on the second is 32bit. – user4341206 Jun 08 '15 at 15:45
  • 4
    add `-XX:+PrintFlagsFinal` as last VM flag, capture the output and run a diff. 32bit and 64bit VMs most likely behave quite differently because the former will likely be classified as client-class machine. Number of threads might also make a difference. – the8472 Jun 08 '15 at 15:46
  • 1
    Just because all the things you actually configured are the same doesn't mean there aren't things under the hood that it does differently on 64-bit vs 32-bit platforms. Also, java datatypes don't necessarily get packed. Depending on what you're doing, a lot of your data might use twice as much space on a 64-bit machine... – Affe Jun 08 '15 at 16:24
  • `+UseCompressedOops` should result in the same packing for 32bit and 64bit systems. maybe apart from object alignment – the8472 Jun 08 '15 at 16:26
  • Or more simply, it is not surprising that an application that only needs as much memory as can be made available on a 32-bit platorm, would perform better on a 32-bit platform. – Affe Jun 08 '15 at 16:26
  • to me that reasoning seems to rest on shaky ground. especially considering he experiences lower GC throughput on the 32bit system. – the8472 Jun 08 '15 at 16:28
  • Are you sure you are running the same java version ? Java 8 does not support Windows XP: http://java.com/en/download/help/sysreq.xml – Svetlin Zarev Jun 08 '15 at 17:04
  • Yes, I'm running same java version (it was installed although it's not officially supported). – user4341206 Jun 08 '15 at 17:09
  • Oops compresses pointers, not data. If it's using less memory to accomplish the same task, of course throughput is lower, there's less to collect. – Affe Jun 08 '15 at 17:25

1 Answers1

3

I would expect than better PC would have much better results but now I don't even know which one is better...

Better is subjective. Depending on whether you need throughput (fraction of CPU cycles spent GCing), sustainable allocation rates, low pause times or low footprint. Generally there's a tradeoff between those goals.

G1GCs is a complex, selftuning beast that behaves differently under different circumstances. So unless there actually problematic behavior which you want to avoid, where's the problem? It just does its job differently.

As mentioned in the comments, if you merely wish to satisfy your curiosity, you can compare VM flags by appending -XX:+PrintFlagsFinal to the options and run a diff. They are probably quite different because 32bit and 64bit systems get different defaults.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • I'll compare flags using -XX:+PrintFlagsFinal as soon I'll have access to both PCs. I have one "stupid" question: were are these flags displayed if I'm running glassfish server (maybe in domain log on startup or somewhere else)? I was just curious why are such difference, I've always thought than one with less major (or full) GC is better than one with more of them... – user4341206 Jun 08 '15 at 16:49
  • normally this is printed to stdout. I don't know what glassfish does, maybe it redirects everything to a logfile. but you don#t have to run glassfish just to print VM options, you can simply use the same options and invoke it manually from `cmd` – the8472 Jun 08 '15 at 16:53
  • Thanks. There are a quite a few difference in flags (in 64 bit version more of them are set to true or are set to higher values) and some are missing in 32 version. – user4341206 Jun 08 '15 at 17:21