JDK-6374905 : SurvivorRatio is ignored when using -XX:+UseConcMarkSweepGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-01-20
  • Updated: 2011-02-16
  • Resolved: 2006-02-21
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
1.4.2_12 b01Fixed
Description
FULL PRODUCT VERSION :
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Server VM (build 1.4.2_10-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
C:\j2sdk1.4.2_10\bin\java.exe -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy -XX:SurvivorRatio=1 -XX:+PrintTenuringDistribution -server -showversion -Xms256m -Xmx256m -XX:NewSize=64m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps test

0.000: [GC 0.000: [DefNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 65405K->0K(65472K), 0.0087114 secs] 65405K->84K(262080K), 0.0088707 secs]

0.192: [GC 0.192: [DefNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 65407K->0K(65472K), 0.0041371 secs] 65492K->86K(262080K), 0.0042598 secs]

0.377: [GC 0.377: [DefNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 65407K->0K(65472K), 0.0037346 secs] 65494K->89K(262080K), 0.0038483 secs]

New generation is set to 64m, GC says that survivor size is only 32K
and copies everything to old generation. which causes full GC
more frequently than necessary


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
execute test , which allocates 1024 bytes for StringBuffer in a loop

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected to see Desired survivor size in megabytes
ACTUAL -
New generation is set to 64m, GC says that survivor size is only 32K
and copies everything to old generation. which causes full GC
more frequently than necessary


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class test
{
	public static void main( String [] args )
	{
		StringBuffer s = null;
		long l = 0;
		while( true )
		{	s = new StringBuffer( 1024 );
			l++;
			if( l % 10000 == 0 )
				System.out.println( l );
		}
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
It was working in JDK 1.4.1 and is fixed in 1.5 but we have to use version 1.4.2_?? which still have this issue

Comments
SUGGESTED FIX For Mantis /src/share/vm/runtime/arguments.cpp arguments.cpp 2c2 < #pragma ident "@(#)arguments.cpp 1.227 06/01/31 13:50:30 JVM" --- > #pragma ident "%W% %E% %U% JVM" 913c913,914 < if (_is_default_max_tenuring_threshold) { --- > if (_is_default_max_tenuring_threshold && > _is_default_survivor_ratio) {
03-02-2006

EVALUATION There is a simple workaround; please see "Workaround" section.
20-01-2006

SUGGESTED FIX The diffs (wrt Tiger) in: file:///net/prt-archiver.sfbay/export2/archived_workspaces/main/baseline/2003/20031023005430.ysr.cms/workspace/webrevs/webrev-2003.10.23/src/share/vm/runtime/arguments.cpp.sdiff.html will need to be suitably translated into appropriate Mantis lingo. Please contact ###@###.### in case of any specific questions.
20-01-2006

WORK AROUND This is a known (arguably EOU) bug, see CR 4854335. An easy workaround is to also set MaxTenuringThreshold to a suitable non-zero value, for example: -XX:MaxTenuringThreshold=8 -XX:SurvivorRatio=4 When the two flags are set together they both take effect. Each by itself is ignored, unless (part of) CR 4854335 is backported. See "Suggested Fix" section for tips on the backport.
20-01-2006