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

[Erik Österlund]

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
>