<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Ramki,<br>
<br>
This is speculation on my part but we don't do anything<br>
at the start of the compaction phase to explicitly<br>
create more parallelism. What I mean is that we<br>
compact into a chunk when it becomes available<br>
and it becomes available when it is empty or<br>
when we can start compacting it into itself. This<br>
conceivably could result in near serial compaction<br>
of the former dense prefix. The extreme example<br>
is 1 small dead object at the beginning of the heap <br>
could allow only 1 chunk to be compacted at a time<br>
in the dense prefix.<br>
<br>
If not allowing maximal compactions does not work,<br>
you might try more frequent maximal compactions.<br>
If there is some adverse situation building up in the<br>
dense prefix, more frequent maximal compactions<br>
might avoid the more extreme degradation.<br>
<br>
Jon<br>
<br>
<br>
On 02/19/12 02:13, Srinivas Ramakrishna wrote:
<blockquote
cite="mid:CABzyjynmqhS1pmNZG8Fk-6mzBC9C9oSHw-_xneGf4VtOw0grOA@mail.gmail.com"
type="cite">Hi Jon --<br>
<br>
After looking at the code and the pattern we observed, we are
pretty confident now that the maximal<br>
compaction was the root of the problem. We are going to
effectively turn off the maximal compaction<br>
and see if it does any harm (don't think it will), and use that to
work around the problem of extreme degradation<br>
when doing parallel compaction. It;s interesting why maximal
compaction would degrade parallel compaction<br>
by so much... some experiments would be useful and perhaps help
correct a specific issue the lack of initial parallelism<br>
may be causing to make the whole collection so much more
inefficient. Hopefully we'll be able to collect some<br>
numbers that might help you folks address the issue.<br>
<br>
later.<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Fri, Feb 17, 2012 at 12:48 PM,
Srinivas Ramakrishna <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ysr1729@gmail.com">ysr1729@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John,
thanks for those suggestions...<br>
<br>
So far the pattern has not repeated, but occurred on two
different servers (in each case it was the<br>
same full gc ordinal too, albeit at different time). There
didn't seem anything external that would<br>
explain the difference observed. Yes, we'll play around a bit
with the compaction related parameters and look at the phase
times<br>
as well. I am also looking at how the dense prefix address is
computed to see if it sheds a bit of<br>
light may be, but it could also be something happening early
in the life of the process that doesn't happen<br>
later that causes this... it's all a bit of a mystery at the
moment. Thanks!<br>
<br>
-- ramki
<div class="HOEnZb">
<div class="h5"><br>
<br>
<div class="gmail_quote">
On Fri, Feb 17, 2012 at 12:10 PM, Jon Masamitsu <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:jon.masamitsu@oracle.com"
target="_blank">jon.masamitsu@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"> Ramki,<br>
<br>
I didn't find a product flag that would print the
end of the dense prefix.<br>
Don't know about jmx.<br>
<br>
The phase accounting (PrintParallelOldGCPhaseTimes)<br>
as you say is a good place to start. The summary
phase is<br>
serial so look for an increase in that phase. Does
this pattern<br>
repeat?<br>
<br>
You could also try changing
HeapMaximumCompactionInterval<br>
and see if it affects the pattern.<br>
<br>
Jon
<div>
<div><br>
<br>
On 2/17/2012 9:46 AM, Srinivas Ramakrishna
wrote: </div>
</div>
<blockquote type="cite">
<div>
<div>
<pre>Hi Jo{h}n, all --
Is there some way i can get at the dense prefix value used for ParOld in
each (major) collection? I couldn't find an obvious product flag for
eliciting that info, but wondered if you knew/remembered.
JMX would be fine too -- as long as the info can be obtained in a product
build.
I am seeing a curious looking log where one specific major gc seems to have
greater user and real time, lower "parallelism" [=(user+sys)/real] and
takes much longer than the rest of the ParOld's. It
also lowers the footprint a tad more (but definitely not proportionately
more vis-a-vis the user time ratios) than the gc's preceding (but not
succeeding) that one, so one conjecture was that perhaps
something happens with the dense prefix computation at that time and we
somehow end up copying more. We'll see if we can get some data with
printing the ParOld phase times, but i wondered if
we might also be able to elicit the dense prefix address/size. I'll
continue to dig around meanwhile.
thanks for any info!
-- ramki
</pre>
</div>
</div>
<pre><fieldset></fieldset>
_______________________________________________
hotspot-gc-use mailing list
<a moz-do-not-send="true" href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a>
<a moz-do-not-send="true" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
</blockquote>
</div>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a moz-do-not-send="true"
href="mailto:hotspot-gc-use@openjdk.java.net"
target="_blank">hotspot-gc-use@openjdk.java.net</a><br>
<a moz-do-not-send="true"
href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use"
target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>