AutoLock

[Dr Heinz M. Kabutz]

On 2/28/11 12:42 AM, David Holmes wrote:
> 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.
Brian pointed this out to me after I wrote my idea.  Once we go more 
verbose, I think the slight syntactic sugar advantage goes away.  Pity.
> 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.
This sounds like a case of premature optimization to me.
> 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.
Yes, of course.  Plus the database and media classes are now 
AutoCloseable.  All very nice.  I love this construct as it fixes a 
serious flaw in most IO exception code.
>
> 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
>