[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] Deterministic destruction of objects in garbage-collected languages



On Tue, 17 Jul 2007, John Elliot wrote:
> Anything that's "internally-allocated" (i.e. virtual memory) is
> managed by the GC and the programmer doesn't need to worry about it.
>
> Anything that's "externally-allocated" (i.e. file handles, database
> connections) needs to expose a contract that *requires* the
> programmer to explicitly 'release' the resource as soon as they can
> when they're finished with it (this has the advantage that managed
> code can run safely during resource release (e.g. your managed
> logging/instrumentation code)).
>
> The problems around this issue in my view are related to conflation
> of "internal" and "external" (relative to the VM) resources. They're
> two different things, and they shouldn't be treated as if they are
> the same thing.

Btw, if VM developers took this stance, then they could expose a means 
of decorating a type with a "requires external release" semantic (by 
implementing a special interface, for example), and have that semantic 
checked at runtime during "internal release".

That is, when the GC is freeing an object's virtual memory, it could 
check (during a debug build, or contingent on some configuration) that 
the "requires external release" contract had been honoured. That is, 
that the programmer using an API that required them to explicitly 
release an externally allocated resource had kept their part of the 
deal.









-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.