Proposal: Automatic Resource Management

[Peter Mount]

On Sun, Mar 8, 2009 at 9:00 AM, Reinier Zwitserloot <reinier at zwitserloot.com
> wrote:

> We're veering waaay offtopic here; the ARM proposal does not address
> locks. Period. Would everyone be happy if this was added in the 'major
> disadvantages' section?


Yes this is becoming more offtopic but hopefully my comments have brought up
two points:

1: Although Locks are a form of resource, the ARM proposal as is cannot
support them
2: Someone will abuse it to support Lock's at some point with potentially
disastrous consequences.


>
> If locks are truly deemed crucial, or the consensus is that,
> eventhough evidently ARM-as-is can't do locks, people will try anyway
> and the resulting confusion must be avoided, I suggest that the ARM
> proposal is updated to do the right thing when an expression of type
> Lock shows up in a try ( lockShowsUpHere ) { code} block. Someone else
> proposed this before and I can't see any downside to this. It would be
> bad if, for every release, a bunch more types get special uniquely
> defined semantics in relation to the ARM expression, but that seems
> very unlikely. Nobody else has named a use-case that doesn't work in
> vanilla ARM yet seems likely to be abused, other than Lock, IIRC.


Yes I did yesterday.

The one thing I've learned from experience is that a lot of programmers are
lazy when it comes to resources. Although for some resources are cleaned up
occasionally by the garbage collector, most are not and unless the system is
under heavy load the problem doesn't show itself until it's in the live
environment. For this reason I do feel that the ARM proposal would alleviate
this as long as the programmers know that the new construct exists.

Now I do feel that Locks are a form of resource but one that is actively
short lived. Although it seems simple to just write them manually with a try
finally block you'll be surprised how easy it is for someone to miss the
finally block or refactor it out without noticing. In a large system this
can be costly (my gaming background coming in here).

Over the last few years I've ended up wasting so much time debugging a
complex system to locate a deadlock just to find that someone has forgotten
to release a lock. It is this reason why I think the ARM proposal should
support Lock's as a separate use-case.

The main issues with Disposable and Lock that I can see are:

1: Lock is an interface and cannot extend Disposable as that would break
existing code. Also implementing Disposable in the Lock implementations
would not work if you use try( Lock ) as javac would not see it as being
Disposable.

2: Normal resources are already open/active before the try so with
Disposable the try(Disposable) would simply call Disposable.close() at the
end. With Locks they are not active until lock() is called so try(Lock)
would have to call Lock.lock() before the method body and then Lock.unlock()
at the end.

As I said in an earlier email I implement this pattern in JDK1.6 by having a
set of annotations which with a processor inject the try...finally block
around a method thats locked (yes I know annotation processors shouldn't do
this but it's removed the problem completely). Having the ARM proposal would
not just obsolete the hack but make it more flexible (as the hack only works
at the method level).

As for any other use-cases that don't work with the current proposal other
than Lock, I can't think of any at the moment.


>
>  --Reinier Zwitserloot
>
>
> On Mar 8, 2009, at 09:03, Peter Mount wrote:
>
> > On Sun, Mar 8, 2009 at 7:58 AM, Jeremy Manson
> > <jeremy.manson at gmail.com>wrote:
> >
> >> I am aware Lock is an interface.  You wouldn't actually change the
> >> Lock interface, you would change the classes.  Just as they retrofit
> >> Iterable everywhere.  That's why I put "class Lock" there; perhaps it
> >> would have been clearer if it said "class MyLock".
> >
> >
> > What about when someone just references the lock as Lock rather than
> > the
> > implementing class? Javac won't be able to determine that the lock
> > implements Disposable so in that case it will fail..
> >
> >
> >
> >
> >>
> >>
> >> Jeremy
> >>
> >> On Sat, Mar 7, 2009 at 10:23 AM, Stephen Colebourne
> >> <jodastephen at gmail.com> wrote:
> >>> Jeremy Manson wrote:
> >>>> The "right" fix, if we want to support this pattern, is to allow
> >>>> the
> >>>> try resource statement to accept expressions that return
> >>>> Disposables,
> >>>> and to retrofit the relevant lock APIs with disposables and lock
> >>>> methods that return this:
> >>>>
> >>>> class Lock implements Disposable {
> >>>>  public Lock dlock() {
> >>>>    return this;
> >>>>  }
> >>>>  @Override public void dispose() {
> >>>>    unlock();
> >>>>  }
> >>>> }
> >>>>
> >>> Lock is an interface. No changes are possible.
> >>>
> >>> Stephen
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > --
> > Peter Mount
> > e: peter at retep.org.uk
> > w: http://retep.org
> > Jabber/GTalk: peter at retep.org MSN: retep207 at hotmail.com
> >
>
>
>


-- 
Peter Mount
e: peter at retep.org.uk
w: http://retep.org
Jabber/GTalk: peter at retep.org MSN: retep207 at hotmail.com