[9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set

[Tobias Hartmann]

Hi Thomas,

thanks for looking at this!

On 24.05.2016 09:13, Thomas Schatzl wrote:
> Hi Tobias,
> 
> On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote:
>> Hi Dean,
>>
>> On 23.05.2016 20:09, dean.long at oracle.com wrote:
>>> Hi Tobias.  I was just wondering, how do we know that the destination 
>>> object is in Eden, both now and in the future, and what would happen if
>>> it wasn't?  Would we get a nice assert somewhere, or would we end up
>>> with a hard-to-find bug?
> 
> Hard-to-find bug. Please add an assertion.
> 
>>
>> Thanks for the feedback! From reading the G1 code, I assumed that a
>> newly allocated object is always in Eden. Looking at the code again,
>> I'm not sure what happens if the Eden space is full. If allocations
>> may happen in the old generation as well, we need a runtime check for
>> the card value. I don't think we have an assert/verification that
>> checks this.
>>
>> Could someone from GC please verify this? 
> 
>   all "small" object allocations go into eden.
> 
> If eden is exhausted, we either issue a GC, or if we can't, expand eden.
> 
> The only exceptions are large objects ("humongous", > half a region
> size). These always go into old gen directly.

Okay, then we need to check the card value for the object to determine if it is "humongous" and allocated in the old generation. If so, we need to emit a post-write barrier.

How does the GC handle this if ReduceInitialCardMarks is *enabled* and the compiler never emits card marks for newly allocated objects (even if they are allocated in old gen)?

I'll prepare a new webrev.

Thanks,
Tobias

> 
> Thanks,
>   Thomas
> 
>