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

[Roman Kennke]

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/22c9e3f3/signature.asc>