RFR(XS): 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero
Bengt Rutisson
bengt.rutisson at oracle.com
Thu Jan 31 07:35:52 UTC 2013
Hi John,
On 1/30/13 10:51 PM, John Cuthbertson wrote:
> Hi Bengt,
>
> Thanks for looking ove the change
>
> On 1/30/2013 1:18 PM, Bengt Rutisson wrote:
>>
>> Hi John,
>>
>> Nice detective work to find this issue! Based on your very good
>> explanation I think this change looks good!
>>
>> One small detail. I think the comment in JavaThread::exit() is a
>> little confusing. I think you are right in your explanation (and code
>> change) that the deferred card marks need to be flushed for all
>> collectors. But the comment seems to suggest that it only affects G1:
>>
>> 1899 // Flush any deferred card marks. Flushing may add cards to this
>> 1900 // thread's G1 dirty card queue so we have to do this before
>> 1901 // flushing the G1 barrier queues.
>>
>> I would prefer to move this comment in to the G1 specific section
>> where we flush the barrier queues:
>>
>> 1906 // We must flush G1-related buffers before removing a thread from
>> 1907 // the list of active threads.
>> 1908 if (UseG1GC) {
>> 1909 flush_barrier_queues();
>> 1910 }
>>
>> The comment could say something like "For G1, flushing the deferred
>> card marks may add cards to the thread's dirty card queue. So we need
>> to flush the barrier queues after we have flushed the deferred card
>> marks.".
>
> Good suggestions. Done. I would say the latter part a bit differently
> since we need to flush G1 barrier queues anyway but now we have an
> ordering imposed upon us:
>
> // We must flush the G1-related buffers before removing a thread
> // from the list of active threads. We must do this after any deferred
> // card marks have been flushed (above) so that any entries that are
> // added to the thread's dirty card queue as a result are not lost.
> if (UseG1GC) {
> ..
> }
Yes, much better! :)
>> Also, should we update the title of the bug? Should it have the "G1:"
>> prefix since it is not a G1 specific fix?
>
> I'm not sure and don't really have a preference. My only concern is
> that the original problem was reported against G1 (and I don't think
> I've seen any issue with the other collectors that could be traced to
> this). Keeping the G1 might make it easier for SQE and others to find
> this CR when triaging other G1 test failures.
OK. I don't have strong opinions about it. Let's leave the title as it is.
Bengt
>
> Thanks,
>
> JohnC
>
More information about the hotspot-gc-dev
mailing list