RFR: 8331117: [PPC64] secondary_super_cache does not scale well

[Andrew Haley]

On Mon, 27 May 2024 17:14:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > Why would it not be zero? Some classes don't have secondary super types.
> 
> I had to check for `r_array_length >= 0` here: https://github.com/openjdk/jdk/pull/19368/files#diff-0f708565c9e138b8013165540634368334f5d1df2ba437e39696e9791440050dR2312 The x86 implementation doesn't do that and I wonder why. Doesn't it access stale memory, here?

No, because we already checked that there must be something to look at before calling the slow path.

Invariant: array_length == popcount(bitmap)

> https://github.com/openjdk/jdk/blob/be1d374bc54d43aae3b3c1feace22d38fe2156b6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L4967

If there's a bit set in the bitmap, then there must be a corresponding entry in the array. If we get to the slow path there must be at least two bits set in the bitmap. Therefore, at this point, array_length >= 2.

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

PR Comment: https://git.openjdk.org/jdk/pull/19368#issuecomment-2134088392