value of dense prefix address used?

[Srinivas Ramakrishna]

Hi John, thanks for those suggestions...

So far the pattern has not repeated, but occurred on two different servers
(in each case it was the
same full gc ordinal too, albeit at different time). There didn't seem
anything external that would
explain the difference observed. Yes, we'll play around a bit with the
compaction related parameters and look at the phase times
as well. I am also looking at how the dense prefix address is computed to
see if it sheds a bit of
light may be, but it could also be something happening early in the life of
the process that doesn't happen
later that causes this... it's all a bit of a mystery at the moment. Thanks!

-- ramki

On Fri, Feb 17, 2012 at 12:10 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

> **
> Ramki,
>
> I didn't find a product flag that would print the end of the dense prefix.
> Don't know about jmx.
>
> The phase accounting (PrintParallelOldGCPhaseTimes)
> as you say is a good place to start.  The summary phase is
> serial so look for an increase in that phase.   Does this pattern
> repeat?
>
> You could also try changing HeapMaximumCompactionInterval
> and see if it affects the pattern.
>
> Jon
>
>
> On 2/17/2012 9:46 AM, Srinivas Ramakrishna wrote:
>
> 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
>
>
>
> _______________________________________________
> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120217/237250a0/attachment.html