An "anti-locked" object is one whose monitor state is set in such a way that locking that object is (subsequently) impossible or impractical.  At the election of a diagnostic switch or other tool, any attempt to lock such an object leads to one of the following outcomes:

- a permanent wait, with a logged message (and perhaps a backtrace)
- an artificially prolonged wait, with a logged message (and perhaps a backtrace)
- a thrown exception, with a logged message (and a backtrace)

The proposed API is internal to the Unsafe class:

void antiLockObject(Object x);

A separate RFE JDK-8236568 calls for a switch to request that the JVM will implicitly anti-lock *all* objects of selected classes (such as jl.Integer).

This is a diagnostic feature, in order to investigate (in the field) whether applications perform "rogue locking" on certain well-known classes, notably java.lang.Integer and the other wrappers, or on the internally generated classes of lambdas.  As a primitive callable on individual instances, it can be installed in factory methods and/or constructors, allowing distinct instantiation paths to be tested independently.

Rogue locking is important to quantify, since it is a compatibility hazard to migrating classes to be inlines.  The performance benefit of an inline class is obtained by giving up on object identity, which means there is, for inline instances, no longer a well-defined identity to host the (stateful) object monitor required by synchronization.  This hazard can be tested before migration by diagnosing rogue locking attempts on normal identity objects, using this feature and/or the class-based one (JDK-8236568).