CRIU: Blocking identity operations in single thread mode

[tajila]

When running in single thread mode certain operations may cause a deadlock. The following are the cases where deadlocks may occur.

1. Contended monitor enters

• If the JVM attempts to acquire a lock that is held by another application thread, this would cause a deadlock since in this mode only a single application thread can be active.
• In this mode the JVM will throw an exception for any contended monitor acquisition, either by bytecode (monitorEnter) or by JNI (MonitorEnter) or java.util.concurrent.locks.Locks.
• In this mode we will also throw for Thread.join()

2. Terminal operations

• Some operations force the thread to block and require another thread to enable resumption. Given that only single thread can be run at a time this would cause a deadlock
• An internal list of known methods that exhibit this behaviour will be created. Examples are sun.misc.Unsafe.park(), java.lang.Thread.suspend.
• Upon entry to these methods the JVM will throw an exception

3. Potentially terminal operations

• Some operations that rely on external resources (sockets, file handles, etc.) may exhibit terminally blocking behaviour if there is a failure in the external system. These cases are addressed by the use of the timeout thread.
• Launch timeout thread that will interupt Java hooks if it exceeds a certain threshold

4. Notify

• Notify potentially transfers control from from the calling thread to the another that is waiting on it. Under normal circumstances it would be acceptable to send notify() and release the lock, then attempt to re-acquire it at another time. However, in single thread mode this will trigger a deadlock.
• The JVM will delay all notify operations until the end of the single thread phase

5. Temporary blocking operations

• Some operations will block temporarily
• Thread.onSpinWait(), yield(), this should be a no-op in single thread mode

[tajila]

@JasonFengJ9 in the short term we can focus on contended monitor enters.