On Thu, 22 Aug 2024 16:23:48 GMT, Roman Kennke <rken...@openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) 
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been 
>> previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All 
>> changes in this PR are protected by this flag. The purpose of the flag is to 
>> provide a fallback, in case that users unexpectedly observe problems with 
>> the new implementation. The intention is that this flag will remain 
>> experimental and opt-in for at least one release, then make it on-by-default 
>> and diagnostic (?), and eventually deprecate and obsolete it. However, there 
>> are a few unknowns in that plan, specifically, we may want to further 
>> improve compact headers to 4 bytes, we are planning to enhance the Klass* 
>> encoding to support virtually unlimited number of Klasses, at which point we 
>> could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In 
>> order to be able to do this, we are add some changes to GC forwarding (see 
>> below) to protect the relevant (upper 22) bits of the mark-word. Significant 
>> parts of this PR deal with loading the compressed Klass* from the mark-word. 
>> This PR also changes some code paths (mostly in GCs) to be more careful when 
>> accessing Klass* (or mark-word or size) to be able to fetch it from the 
>> forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now 
>> uses a bit to indicate 'self-forwarding'. This is needed to preserve the 
>> crucial Klass* bits in the header. This also allows to get rid of 
>> preserved-header machinery in SerialGC and G1 (Parallel GC abuses 
>> preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We 
>> have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, 
>> we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the 
>> GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field 
>> layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, 
>> it is not possible to read an archive that has been written with an opposite 
>> setting of UseCompactObjectHeaders. Some build machinery is added so that 
>> _co...
>
> Roman Kennke has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove hashcode leftovers from SA

src/hotspot/share/gc/parallel/mutableSpace.cpp line 232:

> 230:         p += obj->forwardee()->size();
> 231:       } else {
> 232:         p += obj->size();

I feel it's more correct to go through the forwardee for forwarded objs even 
for the non-COMPACT_HEADERS case. (This method is meant to cover all objs, so 
should not be perf-critical.) IOW, the `false` case should just be dropped.

src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:

> 705:       } else if (obj->is_forwarded()) {
> 706:         // To restore the klass-bits in the header.
> 707:         obj->forward_safe_init_mark();

I wonder if not modifying successful-forwarded objs is cleaner. Sth like:


reset_self_forwarded_in_space(space) {
  cur = space->bottom();
  top = space->top();

  while (cur < top) {
    obj = cast_to_oop(cur);

    if (obj->is_self_forwarded()) {
      obj->unset_self_forwarded();
      obj_size = obj->size();
    } else {
      assert(obj->is_forwarded(), "inv");
      obj_size = obj->forwardee()->size();
    }

    cur += obj_size;
  }
}

reset_self_forwarded_in_space(eden());
reset_self_forwarded_in_space(from());

src/hotspot/share/gc/serial/serialArguments.cpp line 33:

> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
> 32:   GenArguments::initialize_heap_flags_and_sizes();
> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);

Can one use `MaxHeapSize` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727547638
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727524479
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727548413

Reply via email to