ysr1729 at gmail.com
Mon Jul 29 21:29:00 UTC 2013
ah, makes sense! :-)
So, if the scavenge failed, leaving stuff in Eden and the survivor
spaces, the chunks should still be valid if a CMS collection could
(I wonder after asking that question, though, how CMS would deal with
such a situation -- two active survivor spaces, i think it deals OK
with it, but not sure if both scans today parallelized or not, or if
the question is moot because the failed scavenge causes a bail out to
a stop-world gc... perhaps the latter?) Probably an academic question,
but still... :-)
On Mon, Jul 29, 2013 at 1:46 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> This has gotten interesting. When
> 1) a System.gc() is called
> 2) UseCMSCompactAtFullCollection is set to false
> the CMS generation tells GenCollectedHeap that CMS
> does not collect the young gen. That's right but I hadn't
> appreciated that in that circumstance a young gen GC
> was done before the CMS gen is collected. Makes sense
> but the GC epilogue code is called after all the generations
> have been collected by GenCollectedHeap so the
> _eden_chunk_index is not reset between the young GC
> and the CMS GC.
> I think the right fix is to use the occupancy of eden to
> decide what work we need to do instead of _eden_chunk_index.
> On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote:
>> Don't have the code in front of me to check, but yes that would seem to be
>> the thing to do. I thought it was reset in the young gen gc epilogue ...
>> On Jul 26, 2013, at 14:46, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled
>>> and CMSEdenChunksRecordAlways both enabled. The assertion
>>> failure is in do_young_space_rescan()
>>> 5506 assert(mr.is_empty() || space->used_region().contains(mr),
>>> 5507 "Should be in space");
>>> and the failure occurs because _eden_chunk_index is > 0 and
>>> eden is empty.
>>> A young GC has just occurred and a System.gc() is in progress where the
>>> System.gc() is executing the the usual phases of CMS in a stop-the-world
>>> fashion. A rarely seen scenario I think. That is, the initial mark is
>>> I was looking at the places where _eden_chunk_index is reinitialized to
>>> 0. I don't think you added any in you changes, right?
>>> I was thinking that _eden_chunk_index should be reset to 0 after
>>> a young GC where we know that eden is empty. What do you think?
More information about the hotspot-gc-dev