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

[Tobias Hartmann]

Hi Thomas,

[putting hotspot-dev back on CC]

On 24.05.2016 12:41, thomas schatzl wrote:
> Hi,
> 
> On 24.05.2016 11:26, Tobias Hartmann wrote:
>> 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,
> [...]
>>>> 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.
> 
> Humongous allocations always go through the runtime. I do not think the compiler needs to emit code for this case.

Okay, but isn't this only the case if ReduceInitialCardMarks is enabled?

See this comment in library_call.cpp:

// (We can dispense with card marks if we know the allocation
// comes out of eden (TLAB)... In fact, ReduceInitialCardMarks
// causes the non-eden paths to take compensating steps to
// simulate a fresh allocation, so that no further
// card marks are required in compiled code to initialize
// the object.)

Looking at the comments around CollectedHeap::can_elide_tlab_store_barriers(), it seems that the compiler has to notify the runtime when eliding card-marks. The question is if compiled code that emits an AllocateNode can rely on the runtime taking such compensating steps even if ReduceInitialCardMarks is *disabled*? Because I think in this case, the compiler does not notify the runtime.

If not, the compiler needs to emit card marks if the object is not in eden, right?

Thanks,
Tobias

>> 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)?
> 
> Compiled code never allocates into the old gen directly - humongous allocations require a runtime call. So I do not think this needs a change in the compiler after all.
> 
> Sorry for not being specific enough in the first place.
> 
>> I'll prepare a new webrev.
> 
> Thanks,
>   Thomas
>