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

[Tobias Hartmann]

Hi Thomas,

On 24.05.2016 16:33, Thomas Schatzl wrote:
> Hi Tobias,
> 
> On Di, 2016-05-24 at 13:35 +0200, Tobias Hartmann wrote:
>> Hi Thomas,
>>
>> [putting hotspot-dev back on CC]
>>
> 
>   sorry for messing up this...
> 
>> 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?
> 
> Okay, I think I got it. Yes, in case ReduceInitialCardMarks is false,
> the compiler needs to emit the card marks for humongous object
> allocations.

Okay, thanks for clarifying. I'll send out a new webrev soon.

Best regards,
Tobias

> 
> Thanks,
>   Thomas
> 
>