Accommodate changes in Java 15 object layout

[simonbasle]

The way fields are laid out is changing in Java 15, allowing fields from a sub-class to be stored in the unused space of a super-class's field (and breaking the assumption that fields of a sub-class are always laid out after all the fields of the super class).

See https://bugs.openjdk.java.net/browse/JDK-8237767

This can have an impact on the low-level classes that introduce artificial padding to avoid false sharing, like QueueDrainSubscriber or most classes in the reactor.util.concurrent package.

Note that the behavior in question can be manually disabled using a new VM option -XX:-UseEmptySlotsInSupers.

@Contested isn't an option as of JDK 9 due to its sun.misc nature.

The only current durable solution on our side to ensure no false sharing seems to be using the inheritance of padding classes trick, but with boolean padding fields instead of long. This is because on a boolean, you cannot have "unused" space, as the smallest boolean takes as much space as the largest.

[akarnokd]

I bet @nitsanw will love this JDK change.

[simonbasle]

obi-wan-@nitsanw you are my only hope. in the Java 17 timeline, is there a recommendation to avoid false sharing?

I've struggled to replace 15 long padding fields with 120 byte/boolean padding fields. While experimenting I was looking at the layout with JOL (in a test) and it didn't seem to help... That said I might have made some mistake in the process.

I wonder, is -XX:-RestrictContented that much impractical for libraries like us?

We could maybe add diagnostic code that checks if RestrictContented is lifted via the RuntimeMXBean and warn users of perf impact via a WARN log otherwise? 🤔