1.4.2 PrintFLSStatistics Output

[Neeraj Jain]

Hi Ramki,

Thanks for the pain you took to explain the details. Appreciate your help.

Neeraj

On Wed, Aug 20, 2008 at 10:03 PM, Y Srinivas Ramakrishna <
Y.S.Ramakrishna at sun.com> wrote:

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080820/67d638d0/attachment.html