AutoLock

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


Hello.

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:
http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html

> 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 
java.io.Closeable.  There are a few that just implement AutoCloseable:

java.nio.channels.FileLock
java.beans.XMLDecoder
java.beans.XMLEncoder
java.io.ObjectInput
java.io.ObjectOutput
java.sql.Connection
java.sql.ResultSet
java.sql.Statement
javax.sound.midi.MidiDevice
javax.sound.midi.Receiver
javax.sound.sampled.Line

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

-Joe

[1] http://blogs.sun.com/darcy/entry/project_coin_jdbc_4_1
[2] http://blogs.sun.com/darcy/entry/project_coin_bring_close


> 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: 
>> http://www.javaspecialists.eu/archive/Issue190.html
>>
>> Regards
>>
>> Heinz
>>     
>
>   




More information about the coin-dev mailing list