Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods (original) (raw)

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.

-Doug

More information about the core-libs-dev mailing list