Possible issue with clone()

[gacholio]

Noticed while implementing #13192

The order of operations for a clone is:

• allocate new object zeroed
• copy object contents (including lockword) a reference-sized slot at a time
• zero lockword
• GC barrier
• finalize/synchronizer check

The extremely unlikely but possible issue here is that the object allocation will report the JVMTI VMObjectAlloc event if it has been requested. This allows the jobject to potentially become visible to other threads while the rest of the clone is taking place.

Two problems here with the lockword:

• another thread could see the lock value copied from the original object before it gets zeroed
• another thread could lock the object before the clone zeroes the lockword, resulting in a leak in the monitor table and lock misbehaviour

Another issue is that another thread could see a torn long/double values in compressed refs mode as the cloning is not 64-bit atomic.

I'm not sure if there are any problems with:

• reference slot values visible before GC barrier in clone has occurred
• finalizeble/synchronizer object being visible before being linked into the appropriate list

Note that the JVMTI SampledObjectAlloc event has the same issue with the finalizer/synchronizer lists. This applies to all allocations, not just clone.

Note that a GC can occur when the JVMTI event is sent (between the allocate and the start of the field copy).

Practically speaking, no application should ever do this, but we've seen stranger things.

[gacholio]

@tajila @dmitripivkine @amicic

[tajila]

Is it possible to do the allocation without firing the SampledObjectAlloc event?

[tajila]

My understanding is that SampledObjectAlloc is conditional and is not triggered on every allocation, if thats true this should allow us to avoid the event in special cases

[JasonFengJ9]

SampledObjectAlloc is enabled via https://github.com/eclipse-openj9/openj9/blob/99077564bf9bd2a32409b5861e8b8687061cddc0/runtime/jvmti/jvmtiCapability.c#L377-L390

[gacholio]

Is it possible to do the allocation without firing the SampledObjectAlloc event?

At the moment, I don't think so, and I wouldn't be in favour of adding this as an allocation option for such an edge case.