JDK-5089317 : Minor GC collections times adversely affected by very large objects in old gen.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0,5.0u2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux,solaris
  • CPU: generic,x86,sparc
  • Submitted: 2004-08-19
  • Updated: 2005-08-09
  • Resolved: 2004-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u5Fixed 6 b14Fixed
Related Reports
Duplicate :  
Description
###@###.### 2004-08-19

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-rc"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta3-b60)
  Java HotSpot(TM) Client VM (build 1.5.0-beta3-b60, mixed mode)


Does this problem occur on J2SE 1.3, 1.4 or 1.4.1?  Yes / No (pick one)
  No


Operating System Configuration Information (be specific):
  Opteron: dual Opteron 146, 6gb ram, 2x72gb 10k rpm U320W drives in raid0
           Linux 2.4.25, glibc 2.3.2

  x86: dual Xeon 2.6 ghz, 2gb ram, 2x36gb 10k rpm U160W drives in raid0
       Linux 2.4.25, glibc 2.3.2 and tested also with Linux 2.4.20, glibc 2.2.5

Hardware Configuration Information (be specific):

  Opteron: 
     2xopteron 146  
     6gb of ddr ram
  x86: 
     dual xeon with 2.66 Ghz - with enabled hypertread.
     4gb of ram.
  On both systems there is 4gb of swap space - but system does not swap.

Bug Description:
  Having problems with performance of JDK on opteron. When 
  running our aplication(IndexServer) with big index file(13gb),
  performance of it becomes very slow with long GC times - up to 4 seconds
  (changing heap size or options for different gc behaviour doesn't help).
  Tests were made on jdk 1.5.0 beta3 build60, Linux, glibc 2.3.2. When 
  testing same on Intel x86, doesn't make problems.

  Attached 2 verbose gc data for both opteron and x86; gc-opteron-client.log
  and gc-x86-client.log. Both are running with switch -client. There are some
  checkpoints inside log file, which means output from the aplication.
  Checkpoint "IndexDirectory started on //...../TridentIndexDirectory" is 
  line between startup of data and running load on it.

  Best performance of out aplication we got with this JVM parameters:

     -server -XX:+UseSerialGC -XX:+UseAdaptiveSizePolicy

  Using paralel gc or incremental gc brings to 10 times slower performance.
  That is the reason why we are using client VM not server VM.
  Keep in mind that we are only using  2 xeon cpus (which "acts" like 4 cpus).
  We didn't make any tests with paralel gc on machines with more cpus than 2
  (also 2 opteron and itanium cpus)

  We are using MX and MS for sure. Our applications are much  big:

     With intel default settings -  now are 1024 Mb for MX and 768 for MS.
     With opteron it works with 1600 for MX and about 1300 for MS.

  Try to optimize gc with time ratios, which comes with
  -XX:UseAdaptiveSizePolicy, but no special efect.
###@###.### 11/1/04 19:24 GMT

Comments
SUGGESTED FIX The main changes are here: http://analemma.sfbay/net/prt-archiver/data/archived_workspaces/main/gc_baseline/2004/20041102140336.jmasa.gc_baseline_5089317/workspace/webrevs/webrev-2004.11.02/ The above set of changes caused an assert which was fixed in: http://analemma.sfbay/net/prt-archiver/data/archived_workspaces/main/gc_baseline/2004/20041109062743.jmasa.gc_baseline_5089317/workspace/webrevs/webrev-2004.11.09/ Then a performance tweak was putback based on an earlier review suggestion here: http://analemma.sfbay/net/prt-archiver/data/archived_workspaces/main/gc_baseline/2005/20050123112818.jmasa.gc_baseline_5089317/workspace/webrevs/webrev-2005.01.23/ (but use only the changes for 5089317). When backporting, please make sure to get these changes re-reviewed by Jon Masamitsu. ###@###.### 2005-04-20 18:16:27 GMT
20-04-2005

EVALUATION Nothing we can do about this for Tiger, so I'm committing this to Mustang. ###@###.### 2004-08-24 ---------------------------------------------------------------- ###@###.### 2004-08-26 The customer has run some additional tests (with both a large data set and a small data set) and does not see the opteron performance problem (i.e., opteron performance is a little better than the xeon performance). It's not clear why there were the 4 second collections on opteron as originally reported but some tuning of GC was needed to get reasonable performance and those 4 second collections are no longer happening. I'll work with the customer a bit to tune the GC. I'm closing this as not a bug. ###@###.### 2004-09-10 There is a overhead to partitioning the card scanning amoung the parallel GC threads. The current implementation has each thread scan a fixed number of cards at a time. A large old gen requires a large number of partitions and this is causing the overhead of partitioning to become significant. This has only been tested on linux amd64 so it is not known if this is a problem on other platforms (i.e., the overhead of the partitioning may be worse on linux amd64).
23-09-2004

PUBLIC COMMENTS no comment
23-09-2004