Compilers enjoy bulk zeroing the payload of newly allocated objects, as well as performing initializing stores without store barriers. This is okay for young objects, but not old objects.

ZGC guards against this by checking after the thread transition of slow path allocations back to JIT-compiled Java code, if the object exposed is young or old. Old objects cannot be handled, and trigger deoptimization.

However, flip promoted objects may racingly become old after young mark end and before young relocate start. So far, the way ZGC has tried to deal with this, is by checking what the tenuring threshold is to determine whether the object could racingly flip from young to old in this window of time, and then trigger deoptimization conservatively.

However, the tenuring threshold selection process is also concurrent to this promotion check. Hence, it is theoretically possible when the tenuring threshold is lowered, that the logic does not deoptimize, even though the object ends up being racingly flip promoted.

The consequence is that the promotion barriers may be non-monotonic. The object might be exposed to the JIT and its initialization code runs concurrently with promotion barriers that try to ensure we have at least colored null pointers. When this race goes the wrong way, it is possible for the promotion barrier to transition a raw null pointer to a colored null pointer, and then the mutator transitions it back to a raw null pointer. The implication is that when relocate start runs, some reference fields being promoted might not have store-bad pointers. That means that subsequent stores might lose remembered set entries, and then eventually crash and burn because of that.

All the stars in the universe must align for this race to manifest. However, we should guard for it correctly nevertheless.