Currently, whenever a GC operation needs to enqueue reference objects on to the ReferenceHandler thread's pending list, the GC is supposed to synchronize with the ReferenceHandler thread. This synchronization is achieved by means of the pending list lock. The pending list lock is a Java level monitor and the ReferenceHandler thread owns the monitor while draining the pending list - periodically releasing and waiting on the monitor.

Since the pending list lock is a Java level monitor - non Java threads can't lock it directly.

During a typical GC, the pending list lock is obtained in the gc_prologue() method of the GC VM_Operation. This method is executed by the thread requesting the GC - a Java thread - so it can directly lock the pending list lock.

With concurrent GC operations the thread requesting the VM operation is usually a ConcurrentGCThread and not a Java thread. Thus it can't manipulate the pending list lock directly. Instead it employs the SurrogateLockerThread. The SLT is a daemon Java thread whose raison d'etre is to maniplate (acquire and release) the pending list lock on behalf of the non-Java concurrent GC thread.

Recently we had a case where the pending_list lock was not held on behalf of a concurrent GC operation that pused reference objects on to the pending list. See CR 7099824.

To avoid this situation in the future we should check that the pending list lock is held on behalf of the GC before enqueuing any reference objects.

A suitable and simple check could be to record the thread requesting a particular VM operation and check that the PLL is held by the requesting thread or the SLT prior to enqueuing.