Thu, 01 Apr 2010 16:10:27 -0700 Merge
trims [Thu, 01 Apr 2010 16:10:27 -0700] rev 5083
Merge
Thu, 18 Mar 2010 12:14:59 -0400 6935821: G1: threads created during marking do not active their SATB queues
tonyp [Thu, 18 Mar 2010 12:14:59 -0400] rev 5082
6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc
Mon, 22 Mar 2010 02:40:53 -0700 Merge
apetrusenko [Mon, 22 Mar 2010 02:40:53 -0700] rev 5081
Merge
Thu, 18 Mar 2010 13:31:51 -0700 6935839: excessive marking stack growth during full gcs
jcoomes [Thu, 18 Mar 2010 13:31:51 -0700] rev 5080
6935839: excessive marking stack growth during full gcs Summary: process one item at a time from the objarray stack/queue Reviewed-by: apetrusenko, tonyp
Thu, 18 Mar 2010 01:48:28 -0700 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant")
apetrusenko [Thu, 18 Mar 2010 01:48:28 -0700] rev 5079
6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") Summary: If CM task was aborted while scanning the last object of the specified region and the size of that object is equal to bitmap's granularity then the next offset would be equal or over the region limit which is exactly what the assertion states. Reviewed-by: ysr, tonyp, jmasa
Thu, 11 Mar 2010 11:44:43 -0800 6755988: G1: assert(new_obj != 0 || ... "should be forwarded")
johnc [Thu, 11 Mar 2010 11:44:43 -0800] rev 5078
6755988: G1: assert(new_obj != 0 || ... "should be forwarded") Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous. Reviewed-by: iveresov, tonyp
Mon, 15 Mar 2010 02:56:45 -0700 Merge
apetrusenko [Mon, 15 Mar 2010 02:56:45 -0700] rev 5077
Merge
(0) -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip