CMS parallel initial mark
Jon Masamitsu
jon.masamitsu at oracle.com
Mon Jun 17 14:43:35 UTC 2013
On 6/17/13 2:25 AM, Thomas Schatzl wrote:
> hi,
>
> On Thu, 2013-06-13 at 12:27 -0700, Hiroshi Yamauchi wrote:
>> - instead of checking whether _eden_chunk_array is
>> NULL to detect
>> whether you can sample I would prefer if the same
>> predicate as in the
>> initialization (gch->supports_inline_contig_alloc())
>> were used.
>> (I think the change just copied what was done in the
>> previous version of
>> concurrentMarkSweepGeneration.cpp:4515 has been done)
>>
>> Maybe create a new predicate for that, used
>> everywhere.
>>
>> (btw, throughout this code there is a lot of checking
>> whether some
>> NEW_C_HEAP_ARRAY returned NULL or not, and does
>> elaborate recovery -
>> however by default NEW_C_HEAP_ARRAY fails with an OOM
>> anyway... - but
>> that is certainly out of scope)
>>
>>
>> Thomas, could you file a CR for fixing that? Thanks.
>>
>>
>> Thomas, by a new predicate, do you mean checking
>>
>> if (gch->supports_inline_contig_alloc())
>>
>> as opposed to
>>
>> if (_eden_chunk_array != NULL)
>>
>> assuming that the NEW_C_HEAP_ARRAY succeeded?
>>
> If it did not succeed, the NEW_C_HEAP_ARRAY will exit the VM. This check
> is more because _eden_chunk_array is not initialized with a non-NULL
> pointer in all cases - exactly if supports_inline_contig_alloc() is not
> true, no space will be allocated for it.
>
> That's why such guards are needed.
>
>> You're right that the code checks the null-ness of _eden_chunk_array
>> as CMSCollector::sample_eden() did so.
>>
>> I see that CR 8016276 was filed. Given this, but without knowing the
> 8016276 is about that there is no point in having allocation failure
> handling when the VM exits anyway on allocation failure.
>
>> details of the CR, it seems OK for this patch to keep the null check
>> against _eden_chunk_array as it is?
>>
> Yes, keep it. Also Jon seems to prefer it that way.
Yes.
Thanks.
Jon
>
> Thomas
>
>
More information about the hotspot-gc-dev
mailing list