[master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode

[Roman Kennke]

On Sun, 16 Mar 2025 17:11:49 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Can you articulate why object cannot grow?

Yes.
The way PSParallelCompact currently works: it collects liveness information during the marking phase. At the end of it, we know precisely how many words are live in each reagion. In this phase, we also determine where objects cross region boundaries. Then, during the summary phase, it uses this information to determine which source regions get compacted into which target regions. It also determines the addresses at which a region gets split - that is the part below the split-point gets compacted into one region, and the part above the split point gets compacted into another region. Then, during the forwarding phase, all those infos are used to calculate the target addresses for each object in parallel. It is now possible to divide the forwarding work across several GC worker threads because we know exactly where each region gets compacted into.

The problem is that, with compact identity hash-code, we don't know the size of the target object until the forwarding phase. That is because we need to know whether or not an object moves at all, and we don't know that until we do the actual forwarding. It might be a possibility to make the pessimistic assumption that all objects would be moved, and thus might need to grow (if they have an i-hash and no gaps to store it), and then deal with the waste that gets produced, but some of the calculations about the split-points and the locations where objects would cross region boundaries would be thrown off still.

The new approach is much more flexible, and the implementation is much simpler (but it tends to produce more waste).

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

PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2728694713