[Vm-dev] [ENH] A better finalization support (VM & language side)

[Eliot Miranda]

On Sat, Mar 13, 2010 at 3:45 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> Guys, i need your opinion on this.
> What are you generally thinking about this idea?
> If it ok in general, and you want it to be in VM, then i will continue
> with my effort to fix all remarks, which
> Levente and others pointed out.
> But since only Levente and Andreas commented this so far, and i can't
> decide if this feature is accepted by
> others or not.
> If you think this is not the way to go, please explain why you think that.
> Sure thing i, as an author want this change to be integrated.
>

I'm not sure I understand the semantics yet.  Andreas and I discussed it a
little today and we thought that is that it is a way of associating a
finalizer with a specific object such that the such that the object is still
alive when it is finalized.  But now I reread your proposal it looks like
the finalizer gets run only when its object has been collected.

The most important thing is for the finalization system not to be
post-mortem (not run a finalization action when the object is already dead).
 Consider a buffered file.  The finalization action should flush the buffer
as well as close the file handle.  If the finalization is post-mortem then
one finalizes a copy of the file.  Hence to ensure that the copy has the
same buffer state one has to update the copy every time the real file's
buffer changes state, and that's bad for performance.

If I've misunderstood the proposal then please try and write a more
comprehensible specification.  If however the proposal still does
post-mortem finalization then IMO its not worth it and we should try and
implement a pre-mortem scheme where the garbage collector detects when an
object is about to be collected (usually implemented by the GC detecting
when the object is only referenced from finalizers, and queueing the
finalizers).

2¢

cheers
Eliot


> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100313/6db563fc/attachment.htm