RFR: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental) [v3]

Roman Kennke rkennke at openjdk.org
Wed May 10 13:04:33 UTC 2023


On Wed, 10 May 2023 09:24:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow to resolve mark with LW locking
>
> src/hotspot/share/gc/shared/memAllocator.cpp line 414:
> 
>> 412:   // concurrent collectors.
>> 413:   if (UseCompactObjectHeaders) {
>> 414:     oopDesc::release_set_mark(mem, _klass->prototype_header());
> 
> In other cases, we do `markWord::prototype().set_narrow_klass(nk)` -- it looks safer, as we get the `markWord`-s prototype, and amend it. `_klass->prototype_header` can be removed, I think.

I like _klass->prototype_header() more, and would argue that we should use that instead, here. An object's prototype mark really depends on the Klass of the object, with compact headers, and we would always get the correct prototype out of _klass->prototype_header(). Also, perhaps more importantly, the Klass::prototype_header() is useful because we can load it in generated code with a single instruction, while fetching the markWord::prototype() and amending it *at runtime* would require a whole sequence of instructions.

We only use markWord::prototype().set_narrow_klass(nk) in CDS, where the correct encoding of the narrow-klass in the header depends on the relocated Klass* location, and we couldn't safely use Klass::prototype_header().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13844#discussion_r1189873545


More information about the hotspot-dev mailing list