Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

[Paul Sandoz]

On Mar 5, 2014, at 3:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> A few comments on catching up with this discussion...
> 

Same here, back from a holiday last week.


>>>> 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.
> 

Thanks, useful information. 

I would have expected if this offered a perf advantage that the resourceful Unsafe users would have found a use for it :-)

Currently i cannot find any external uses of it.

Paul.


> 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
>