RFR: JDK-8211270: GC abstraction to get real object and headers size

[Roman Kennke]

Yes. Thank you!

It would indeed be useful. It could be used in the various allocation
and size paths, as well as in the filler-object-handling (which is just
a variation of alloc and size). We used to have oop_extra_words() API in
Shenandoah (until now). This could be renamed to:

virtual size_t cell_extra_words() { return 0; }

and:

size_t cell_words(oop obj) { return obj->size() + cell_extra_words(); }

and then all the allocation and size paths could use those two methods.
E.g. the TLAB alloc path in interpreter would emit one extra 'add
cell_extra_words()' instruction to dynamically extend the alloc-size (if
it's != 0).

That being said, what we have now (including "JDK-8211955: GC
abstraction for LAB reserve" if you could review that) works for me, and
it hides the concept of 'cells' from the rest of the runtime, and keeps
it completely at the discretion of the GC (with the exception of this
patch, which exposes the cell-size to whitebox and jvmti).

I'll push the change as-is if jdk/submit comes back clean.

Thanks for reviewing and your input!
Roman

> Hi Roman,
> 
> I think you can keep it as obj for now, as the concept of a cell is not
> yet introduced.
> We can sort it out later instead when we know better what we want to do.
> 
> Thanks,
> /Erik
> 
> On 2018-10-10 10:29, Roman Kennke wrote:
>> Hi Erik,
>>
>> Your reasoning makes sense. A simple solution (for this particular
>> patch) would be to rename obj_size() to cell_size() in CollectedHeap.
>> But of course, the other APIs would have to be made consistent with this
>> change too, so...
>>
>>> Hi Roman,
>>>
>>> I think this looks good for now. But I thought I should still mention an
>>> idea I have had since before even setting food in HotSpot. I have always
>>> thought of "cells" and "objects" as different things. Cells, to me, are
>>> chunks of memory allocated by an allocator (possibly with its own
>>> header), and objects are the things we initialize into these cells. It
>>> just happens to be that cells and objects have had the same size up
>>> until now, and we never initialize anything else than objects inside of
>>> our cells. With the introduction of Shenandoah, cells and objects are
>>> once again different, to the extent that we need these type of APIs. The
>>> cell header is at a negative offset, and the object header at the base
>>> pointer. The cell size includes the cell header, the object size does
>>> not.
>>>
>>> So to me, it is not obvious when we are asking for the cell size as
>>> opposed to the object size without being explicit about it. In your
>>> changes, you make the object size the cell size, trying to keep them the
>>> same, and not expose the cell abstraction. For example, the whitebox API
>>> when asking for the object size, always gets the cell size. But it's not
>>> obvious to me that you always want to know the cell size and never the
>>> object size. I suppose now the distinction can be made by simply not
>>> calling this API that slaps on the cell header size.
>>>
>>> So for me, introducing a distinction between objects and cells, so we
>>> always know which one of the two we are referring to, would make things
>>> less confusing and more precise.
>>>
>>> Having said all this, I don't know exactly what I would like that to
>>> look like, and I don't want to block anything based on a vague idea. So
>>> I'm okay with doing things this way now, and perhaps we think a bit
>>> about this until another day, and see if we can come up with something
>>> even better eventually.
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 2018-10-09 16:39, Roman Kennke wrote:
>>>> Hey Aleksey,
>>>>
>>>>> On 10/05/2018 06:20 PM, Roman Kennke wrote:
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8211270/webrev.00/
>>>>> Do we really need the abstractions for header sizes? I think all
>>>>> usages need the object size, and
>>>>> header sizes can be just picked up from the usual places. No GC,
>>>>> including Shenandoah is changing
>>>>> the header size?
>>>>>
>>>>> Trying to understand the use case, looking at Shenandoah's diff here:
>>>>>
>>>>> https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/latest/src/hotspot/share/gc/shared/plab.cpp.sdiff.html
>>>>>
>>>>>
>>>>>
>>>>> ...it seems what we really want is to mix in oop_extra_words into
>>>>> plab.cpp accessors. Because doing
>>>>> ShenandoahHeap::obj_header_size() { return obj_header_size +
>>>>> oop_extra_words; } seems wrong down the
>>>>> line -- it would _not_ be the header size.
>>>> It seems that the PLAB stuff does indeed require a different kind of
>>>> abstraction, and most likely something that can be shared with, e.g.,
>>>> TLAB in the form of a virtual version of CollectedHeap::min_fill_size()
>>>> or such. Let's take this part out of the patch:
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8211270/webrev.01/
>>>>
>>>> Good now?
>>>>
>>>> Roman
>>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181010/9d823a01/signature.asc>