On Mar 5, 2014, at 3:04 PM, Doug Lea <d...@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 >