United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6374905 : SurvivorRatio is ignored when using -XX:+UseConcMarkSweepGC

Details
Type:
Bug
Submit Date:
2006-01-20
Status:
Resolved
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2006-02-21
Component:
hotspot
OS:
windows_xp
Sub-Component:
gc
CPU:
x86
Priority:
P5
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:
1.4.2_12 (b01)

Related Reports

Sub Tasks

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) {
                                     
2006-02-03
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.
                                     
2006-01-20
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.
                                     
2006-01-20
EVALUATION

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



Hardware and Software, Engineered to Work Together