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

[Erik Österlund]

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
>>>