GC object finalization not guaranteed

Leandro Lucarella llucax at gmail.com
Sat Apr 18 15:18:01 PDT 2009


Fawzi Mohamed, el 18 de abril a las 23:41 me escribiste:
> >>when the main thread ends other threads might be running, and removing
> >>memory they are using is not necessarily a good idea.
> >Then I guess gc_term() should be invoked when all threads have terminated.
> >Is there any technical difficulty to do that?
> 
> well killing a daemon thread might not be so easy, the cleanest thing
> would be to simulate an exception into it and unwind the stack.  If you
> are not careful you might kill a thread when it did acquire a lock that
> might deadlock your own thread.

But don't you agree that if a thread live longer than the GC, there are
a lot of problems to take care of? I see that scenario as a very rare
special case, not as a reasonable default. I guess some mechanism (like
gc_setTermCleanupLevel()) can be provided to tell the GC not to call
finalizers can be good enough for that special cases. And in that cases,
it's completely acceptable that the finalization guarantee is not provided
(but just because you asked not to be provided).

> >>Exceptions might delay things indefinitely and allocate more memory.
> >Then I guess gc_term() should be invoked when all exceptions were
> >processed. Is there any technical difficulty to do that?
> 
> this should be sort of doable (without having looked at the details)

I don't see a problem with this either.

> >I really didn't take a look at the compiler runtime stuff, so I don't
> >really know how all that works.
> >>Actually with tango you can tweak what will happen with
> >>gc_getTermCleanupLevel (in gc.d), but I don't think that there is
> >>a satisfying solution for everybody.
> >Yes, I saw that (I commented about that in the blog post), but there is
> >still no option to run the finalizers to all the live objects.
> 
> well you could try to ignore all roots but the gc ones (you don't want
> to deallocate it before you have finished using it :).

If the program ends, if the GC ends, you shouldn't be using any GC
allocated memory in the first place, don't you?

> >Anyways, I wonder why it's not part of the GC specs in druntime.
> >>I think that the default in tango is quite reasonable (normal collect).
> >Yes... With the current specs at least, I guess.
> >I think that if finalization is not guarantee, at least at
> >program exit, there shouldn't be there. It's useless.
> 
> not true, there are still cases in which it is useful (weak, ref, and
> what Robert Jaques said.

Ok, it's useful for memory related bookkeeping. That's true. But it's too
easy to introduce bizarre bugs for managing other resources.

And I think providing finalization guarantee is not that hard either.

> Actually one of the first comment when I added gc_setTermCleanupLevel,
> was nice so now my program can finish faster, not everybody wants to
> wait too long after the program has finished doing useful stuff for it
> to die.

Again, I'm not talking about collection. I really don't think the programs
should do a collection before it ends, it has no point, who am I freeing
memory to? What I think it's it necessary is to call the finalizers of the
live objects. Another way to see things is the program has not "finished
doing useful stuff" until all finalizers are called, because finalizers
are supposed to be useful =)

> >Finalization should be possible only for scope classes if no finalization
> >guarantee can be provided by the GC. It's useless and error prone
> >(introducing a bug very difficult to track). Who wants randomly executed
> >destructors?
> 
> destructors are executed in a randmized order (so you might consume an
> external resource if it is limited). That they might not be executed at
> all, is only a small extra problem. Indeed they are less useful than
> (for example) C++, but can still have some uses.

I'm not talking about order when saying "randomly", I'm talking about the
destructor being executed at all =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y ya no tengo colores, sólo gris y negro
Aquí donde el amor es de hierro
Los días pasan y moriremos contando el tiempo



More information about the Digitalmars-d mailing list