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@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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use