RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()

Kim Barrett kim.barrett at oracle.com
Fri Nov 2 21:26:13 UTC 2018


> On Nov 2, 2018, at 7:51 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> So that takes me back to my original intuition: isn't this the same as checking at the very top: if (offset == BrooksPointer::byte_offset()) return false;
> 
> If it really is as simple as just that, and I did not miss something not obvious, then perhaps we would be better off abstracting a cell header check here, as opposed to wrapping the whole thing in a virtual member function. Especially since there are now a number of these occurrences where some basic knowledge about cell header size that is 0 for all GCs except Shenandoah where it is 8, leaves us wrapping a whole bunch of stuff behind a GC interface, only to handle that one difference.
> 
> While I don't know exactly what this cell abstraction would reasonably look like in its full shape, perhaps we could start with something simple like a virtual member function size_t cell_header_size() on CollectedHeap with a suitable comment explaining that a cell header is a GC thing we sometimes put above the object header. And then see if there are more related functions that lead us to a helper class for cells or something like that.
> 
> I'm open to suggestions of course. Thought I'd check with you if this sounds sane to you. Of course if my assumption is wrong that this check could be written much simpler than it looks like, then I suppose I need to give up on that idea. It all boils down to that really.

I think Erik makes some good points here.  At least for now, I’m withdrawing my approval of the changes offered so far.



More information about the hotspot-gc-dev mailing list