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

[Thomas Schatzl]

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.

Thanks,
  Thomas