1.4.2 PrintFLSStatistics Output

[Y Srinivas Ramakrishna]

Hi Neeraj --

> Thanks Ramki. This has cleared lots of our doubts. To complete the
> discussion I have one more query left in the same context.
> 
> We have seen the YG promotions succeeding with BinaryTreeDictionary
> containing Max Chunk Sizes as small as 600 words (4800 bytes) though Total
> Free Space was much higher. Does that mean that, in addition to not
> requiring space to accommodate full Eden+From spaces, java 1.4.2_17 no
> longer has the constraint needing "*single contiguous memory chunk*" 
> also to
> accommodate all the promoted objects in old generation?

Yes. Perhaps I was not clear on how this works and why we needed the
more pessimal "single contiguous memory chunk" restriction until recently in
1.4.2_XX.

Basically, previous to the fixes that allowed us to bail out midway
from a failed scavenge, scavenges would be "all or nothing". We _had_ to
be absolutely certain that all of the objects surviving a scavenge
could be accomodated in the old generation because we did not have
the means to "interrupt" a (failed) scavenge mid-way and revert to
full mark-sweep compact. The simplest way of guaranteeing that a scavenge
succeeded would be of guaranteeing that the old gen had a single
contiguous free block that could accomodate all of eden + survivor.
However, once we had the means of bailing from a failed scavenge
to a full mark-sweep compact, we could now relax that guarantee,
and instead try to _estimate_ with high probability when a scavenge
would succeed. (In our case, I think we took the simple route of
relying on the sweeper to estimate block demand correctly -- something
that we do fairly well when block size distribution is stationary and
there's sufficient space in the old generation to absorb occasional
volatility -- and somewhat optimistically assume that if there's
enough free space in the old generation that scavenges will
succeed. Of course, when these assumptions break down, as they sometimes
do, when there is not sufficient space in the old generation or
we fail in correctly estimating block demand, then scavenges do
fail and in that case we bail to full mark-sweep compact at some
considerable cost in terms of pause-time.)

Hope that answered yr question.
-- ramki 
> 
> Regards,
> Neeraj
> 
> On Tue, Aug 19, 2008 at 11:12 PM, Y Srinivas Ramakrishna <
> Y.S.Ramakrishna at sun.com> wrote:
> 
> >
> > Hi Neeraj --
> >
> > Good question; this has come up in another recent discussion on
> > this list.
> >
> > > I still have a query on your answer to question #2. As I understand,
> > > for a
> > > YG promotion to be successful GC needs a contiguous memory chunk equal
> > > to
> > > the sum of sizes of Eden and From space which comes out to be approx.
> > > 230 MB
> > > in our case. The total free space in the "BinaryTreeDictionary"
> > containing
> > > larger blocks is only ~2.8 MB but the promotions are still succeeding.
> > >
> > > My question is: *where the GC is getting the contiguous memory chunk
> > > of 230
> > > MB from?*
> >
> >
> > That was indeed the old constraint in the early versions of 1.4.2,
> > which was fixed in some early version of 5.0 (if i recall correctly) 
> so
> > that we could handle "promotion failure" (where mid-scavenge we
> > discover that we have no space in the old gen to promote a live
> > object from the young gen). That code was subsequently also backported
> > to some version of 1.4.2, probably 1.4.2_11 or later (i am not
> > sure precisely which version, but can find out if you really care).
> > As a result, (at least) in 1.4.2_17, in fact, there isn't such a
> > restriction,
> > and scavenges will occur even in the absence of the pessimal "full
> > promotion guarantee".
> >
> > -- ramki
> >
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://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