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