Joe Darcy joe.darcy at
Mon Feb 28 10:21:54 PST 2011


David Holmes wrote:
> Hi Heinz,
> One slight glitch here is that, as I recall (and I'd like Joe to confirm 
> as I can't find anything in writing) they updated the spec to disallow 
> simple expressions, so you need to use something slightly more verbose 
> that introduces a local variable to refer to the Lock.

That is correct; the rationale for this change was given in:

> Also as I understand it escape-analysis is only used by the server 
> compiler, so we can not rely on having it to get rid of the object 
> creation overhead. As indicated in the other threads on coin-dev there 
> are ways to do this without having to introduce a new object as a 
> wrapper - but they introduce their own overheads.
> By the way, the "whopping 553 classes" that implement AuoCloseable comes 
> about due to Closeable being retrofitted to also be AutoCloseable. No 
> big surprise that these are primarily (all?) I/O related classes.
Most types that implement AutoCloseable do so by implementing  There are a few that just implement AutoCloseable:


Retrofitting JDBC with AutoCloseable occurred after the initial library 
changes [1].  For those wishing to retrofit types in a codebase to 
implement Closeable or AutoCloseable, an annotation processor is 
available to assist [2].



> Cheers,
> David Holmes
> Dr Heinz M. Kabutz said the following on 02/28/11 05:30:
>> Hi,
>> Brian told me about the discussion going on here on coin-dev.  I 
>> published a newsletter today on the new Java 7 try-with-resource 
>> construct and how we could use it for automatically unlocking.  By 
>> combining it with static imports, we can write the following code:
>>     try (lock(lock)) {
>>       printLockStatus();
>>     }
>> Instead of the current more verbose
>>     lock.lock();
>>     try {
>>       printLockStatus();
>>     } finally {
>>       lock.unlock();
>>     }
>> In my newsletter, I expressed the same concern as Neal, that 
>> constructing objects, and in fact encouraging people to do this in 
>> performance critical code, could be a killer for this idea.
>> However, initial tests indicate that escape analysis actually does a 
>> nice job of eliminating the cost of the object construction.  These are 
>> just completely basic initial tests and are quite possibly flawed.  
>> However, with the default escape analysis turned on, my try (lock(lock)) 
>> code did not cause any objects to be created, even though I called it 
>> 1_000_000_000 times.
>> When I turned off escape analysis, it constructed about 30GB of objects.
>> As I said, I have not tested this properly, just an initial investigation.
>> Here is the link to my article: 
>> Regards
>> Heinz

More information about the coin-dev mailing list