Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

Doug Lea dl at cs.oswego.edu
Wed Mar 5 14:04:16 UTC 2014

A few comments on catching up with this discussion...

>>> tryMonitorEnter() does no harm and it is out of reach of most
>>> programmers.

Built-in monitors are heavily optimized for "typical" cases,
which does not include any form of tryLock. So the hotspot
implementation of tryMonitorEnter is very slow. Making
it less slow would probably negatively impact typical cases.
So tryMonitorEnter is only useful in cases where you absolutely need
the functionality at any cost, and don't want to use a j.u.c Lock.
It's not surprising that there almost no known usages, and
probably none that justify continued support.

The main downside of using a j.u.c Lock just for the sake
of tryLock is that you cannot take advantage of the JVM's
extremely compact lock representation (basically one bit in the
object header) for never-locked objects. On the other hand,
if you are trying to minimize footprint, there are usually
ways to cope. For example, in a few places inside j.u.c. we've used
other available bits as spinlocks and resorted to monitors/Locks
only when necessary. In a sense, this emulates monitor inflation.


More information about the core-libs-dev mailing list