<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">This is great news!
Congratulations!<br>
<br>
-John<br>
</font><br>
Paul Hohensee wrote:
<blockquote cite="mid:49A6DAFC.5040808@sun.com" type="cite">Wow!
<br>
<br>
Paul
<br>
<br>
Igor Veresov wrote:
<br>
<blockquote type="cite">Fixed 6720309: G1: don't synchronously update
RSet during evacuation pauses
<br>
Fixed 6720334: G1: don't update RSets of collection set regions during
an evacuation pause
<br>
<br>
During evacuation pauses in G1 the move of an object might cause
remembered set entries to be updated. Right now, we do those
synchronously (i.e, they are updated there and then and are visible at
the end of the collection). Unfortunately, those synchronous updates
impose a non-trivial overhead on the GC pauses. The fix uses the
existing concurrent refinement thread to update RSets concurrently -
the cards for the update objects are put into update buffers and
processed after the collection.
<br>
<br>
In addition, we don't need to update remembered sets of any of the
regions in the collection set. We explicitly keep track of references
into the collection set during remembered set scanning, so there's no
point in actually updating the remembered sets. Also, after the
collection, all regions in the collection set will be reclaimed, along
with their remembered set, so it is pointless to actually update their
remembered sets.
<br>
However in the case of the evacuation failure we must perform these
updates. The fix delays the updates until it's clear that the
evacuation failure has occurred and schedules them to be applied
concurrently after the collection.
<br>
<br>
As a result of the fixes (measured on sunfire x4200 (2x2 Opteron)):
<br>
- copy time improved 30%
<br>
- synchronous Rset update improved 30%
<br>
- total collection pause time improved 20-25%%
<br>
<br>
Also fixed an issue with the pause time computation in the concurrent
refinement thread.
<br>
<br>
Webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~iveresov/6720334/webrev.00/">http://cr.openjdk.java.net/~iveresov/6720334/webrev.00/</a>
<br>
<br>
Testing: specjbb2005, specjbb2000, jprt
<br>
<br>
igor
<br>
</blockquote>
</blockquote>
</body>
</html>