<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Igor,<br>
<br>
Yeah G1 has that facility right now. In fact you added it. :) When
the number of completed buffers is below the green zone upper limit,
none of the refinement threads are refining buffers. That is the
green zone upper limit is number of buffers that we expect to be
able to process during the GC without it going over some percentage
of the pause time (I think the default is 10%). When the number of
buffers grows above the green zone upper limit, the refinement
threads start processing the buffers in stepped manner. <br>
<br>
So during the safepoint we would process N - green-zone-upper-limit
completed buffers. In fact we could have a watcher task that
monitors the number of completed buffers and triggers a safepoint
when the number of completed buffers becomes sufficiently high - say
above the yellow-zone upper limit.<br>
<br>
That does away with the whole notion of concurrent refinement but
will remove a lot of the nasty complicated code that gets executed
by the mutators or refinement threads.<br>
<br>
My main concern is that the we would be potentially increasing the
number and duration of non-GC safepoints which cause issues with
latency sensitive apps. For those workloads that only care about 90%
of the transactions this approach would probably be fine.<br>
<br>
We would need to evaluate the performance of each approach. <br>
<br>
The card cache delays the processing of cards that have been dirtied
multiple times - so it does act kind of like a buffer reducing the
potential for this issue.<br>
<br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On 6/28/2013 12:47 PM, Igor Veresov
wrote:<br>
</div>
<blockquote
cite="mid:AA908111-B24A-45E5-B536-F9D5356F77B7@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
The impact on the next collection however can be bounded. Say, if
you make it have a safepoint to reap the buffers when the number
of buffer reaches $n$, that alone would put a cap on the potential
pause incurred during the collection. The card cache currently has
the same effect, sort of, right?
<div><br>
</div>
<div>igor<br>
<div><br>
<div>
<div>On Jun 28, 2013, at 12:26 PM, John Cuthbertson <<a
moz-do-not-send="true"
href="mailto:john.cuthbertson@oracle.com">john.cuthbertson@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF"> Hi Igor,<br>
<br>
<div class="moz-cite-prefix">On 6/28/2013 9:47 AM, Igor
Veresov wrote:<br>
</div>
<blockquote
cite="mid:0797C324-BE96-4A60-9154-B23FED4B6A43@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<base href="x-msg://368/"><br>
<div>
<div>On Jun 28, 2013, at 7:08 AM, "Doerr, Martin"
<<a moz-do-not-send="true"
href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div link="blue" vlink="purple"
style="font-family: Helvetica; font-size:
medium; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; " lang="DE">
<div class="WordSection1" style="page:
WordSection1; ">
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">Hi
Igor,<o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US"> </span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">we
didn’t find an easy and feasible way to
ensure the ordering, either.<o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">Grabbing
the buffers and cleaning the cards at
safepoints might be the best solution.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Would anybody from the G1 team like to think
about that?</div>
</div>
</blockquote>
<br>
I've been thinking about this issue on an off for the
last few weeks when I get the time. I mentioned it to
Vladimir a couple of times to get his input.<br>
<br>
<blockquote
cite="mid:0797C324-BE96-4A60-9154-B23FED4B6A43@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<div link="blue" vlink="purple"
style="font-family: Helvetica; font-size:
medium; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; " lang="DE">
<div class="WordSection1" style="page:
WordSection1; ">
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US"><o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US"> </span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">Maybe
removing the barrier that flushes the
store to the cardtable makes the problem
more likely to occur.<o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">I
guess the purpose of the barrier was
exactly to avoid this problem<o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US">(which
should be working perfectly if the post
barriers had StoreLoad barriers, too).<o:p></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif; "><span style="font-size:
11pt; font-family: Calibri, sans-serif;
color: rgb(31, 73, 125); " lang="EN-US"> </span></div>
</div>
</div>
</blockquote>
<br>
<div>Yeah, but like you noted that would have a
horrific effect on performance. So, it's probably
best to bunch the work up to at least eliminate
the need of extra work when, say, you're looping
and storing to a limited working set (G1 uses the
cardtable basically for that purpose). The
safepoint approach will likely require more memory
for buffers and the load will be spiky, and if the
collection were to happen right after we grabbed
the buffers the collector will have to process all
of them which is not going to work well for
predictability. But nothing better comes to mind
at this point.</div>
<div>Btw, there are already periodic safepoints to
do bias locking revocations, so may be it would
make sense to piggyback on that. <br>
</div>
</div>
</blockquote>
<br>
Piggy backing on all the other safepoint operations
might work if they happen frequently enough but I don't
know if that 's the case. And as you, even then there
will be times where we haven't had a safepoint for a
while and will have a ton of buffers to process at the
start of the pause.<br>
<br>
It might be worth adding a suitable memory barrier to
the G1 post write barrier and evaluating the throughput
hit.<br>
<br>
JohnC<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>