tonyp [Tue, 13 Sep 2011 12:40:14 -0400] rev 10535
7089625: G1: policy for how many old regions to add to the CSet (when young gen is fixed) is broken
Summary: When refactoring the code for a previous fix, a condition was not correctly negated which prevents the G1 policy from adding the correct number of old regions to the CSet when the young gen size is fixed. The changeset also fixes a small syntactical issue in g1ErgoVerbose.hpp which is causing compiler warnings.
Reviewed-by: brutisso, ysr
jcoomes [Fri, 09 Sep 2011 16:33:13 -0700] rev 10534
Added tag hs22-b05 for changeset 2787676b53cf
jcoomes [Fri, 09 Sep 2011 16:24:12 -0700] rev 10533
7088991: Bump ths hs22 build number to 05
Reviewed-by: johnc
Contributed-by: alejandro.murillo@oracle.com
jcoomes [Fri, 09 Sep 2011 16:17:16 -0700] rev 10532
Merge
stefank [Fri, 09 Sep 2011 14:44:43 +0200] rev 10531
Merge
tonyp [Fri, 09 Sep 2011 05:20:58 -0400] rev 10530
7087717: G1: make the G1PrintRegionLivenessInfo parameter diagnostic
Reviewed-by: brutisso, ysr
brutisso [Thu, 08 Sep 2011 16:29:41 +0200] rev 10529
6929868: G1: introduce min / max young gen size bounds
Summary: Make G1 handle young gen size command line flags more consistently
Reviewed-by: tonyp, jwilhelm
tonyp [Thu, 08 Sep 2011 05:16:49 -0400] rev 10528
7084509: G1: fix inconsistencies and mistakes in the young list target length calculations
Summary: Fixed inconsistencies and mistakes in the young list target length calculations so that a) the calculated target length is optimal (before, it was not), b) other parameters like max survivor size and max gc locker eden expansion are always consistent with the calculated target length (before, they were not always), and c) the resulting target length was always bound by desired min and max values (before, it was not).
Reviewed-by: brutisso, johnc
iveresov [Wed, 07 Sep 2011 18:58:33 -0700] rev 10527
7086226: UseNUMA fails on old versions of windows
Summary: Return correct answers from os::numa_*() for UMA machines or if NUMA API is not supported
Reviewed-by: johnc
ysr [Wed, 07 Sep 2011 13:55:42 -0700] rev 10526
4965777: GC changes to support use of discovered field for pending references
Summary: If and when the reference handler thread is able to use the discovered field to link reference objects in its pending list, so will GC. In that case, GC will scan through this field once a reference object has been placed on the pending list, but not scan that field before that stage, as the field is used by the concurrent GC thread to link discovered objects. When ReferenceHandleR thread does not use the discovered field for the purpose of linking the elements in the pending list, as would be the case in older JDKs, the JVM will fall back to the old behaviour of using the next field for that purpose.
Reviewed-by: jcoomes, mchung, stefank