ysr1729 at gmail.com
Mon Jul 29 19:48:31 UTC 2013
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
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.
>> 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