sample_eden()

[Srinivas Ramakrishna]

Is it reset after a concurrent mode failure or a full gc as well? (i
am guessing it is.)
What's the value at the first chunk_index slot? (Or more precisely
what is the value of _chunk_index; i.e.
how many valid samples are supposed to be there?)

I know we shouldn't be trying to do remote debugging on the mailing
list, but aren't rare events so interesting because of their rareness
? ;-)
-- ramki

On Mon, Jul 29, 2013 at 11:09 AM, Jon Masamitsu
<jon.masamitsu at oracle.com> wrote:
>
> 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 ...
>
>
> It is in fact reset after each young gen GC (in the CMS gen epilogue) so
> this is not my problem.
>
> Jon
>
>>
>> ysr1729
>>
>> On Jul 26, 2013, at 14:46, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>
>>> Hiroshi,
>>>
>>> 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
>>> being
>>> executed.
>>>
>>> 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?
>>>
>>> Jon
>>>
>>>
>>>
>