[Ironpython-users] Some questions about gc and finalizers

[Markus Schaber]

Hi, Jeff,

Von: Jeff Hardy

On Thu, Sep 18, 2014 at 4:10 PM, Stefan Richthofer <Stefan.Richthofer at gmx.de> wrote:
> >> A quick test (on Mono) says "no", but trying with a class that 
> >> declares __del__ doesn't either, so I'd want to hook up a debugger on 
> >> Windows to check for sure. I'm not sure if the backing types created 
> >> by IronPython have finalizers, but I think not (and reading through 
> >> the RefEmit code will take longer than I have right now.)
> >
> > Sounds like IronPython would not support __del__ at all. Is this a basic, maybe well-known issue or are finalizers principally supported, but currently broken?

> I redid my tests by calling GC.Collect() afterwards, and the "normal"
> case works just fine, but not the attached case. So yes, they do work.
> :)

And I just wanted to write a mail and ask whether you made sure that the GC actually kicks in when reading your first mail - it's good I did hesitate and read the whole thread :-)

The asynchrony and non-deterministic nature of the .NET and Java GCs are one of the biggest difference to cPython, this especially gets visible with "unclean" code which relies on the reference counting to release resources (like files).

[...]
> > I have only rough knowledge of .net, but believe it behaves somewhat equal to Java regarding to gc and finalizers.
> > Since IronPython appears to have equal issues, I would offer guidance and discussion if you might want to port the Jython approach.
> > At least I wanted to make you aware of the 
> > __ensure_finalizer__()-method-manual-fix-approach and suggest that if IronPython would ever implement an equal method to agree on a common name for it.

> I thought the .NET GC might store this information already, but no dice. It is available to the profiler API, but that's not really a good way to go about it (unmanaged code, separate DLL, etc.). :)

Sadly, not even the performance counters provide that numbers:
http://msdn.microsoft.com/en-us/library/x2tyfybc%28v=vs.110%29.aspx

I also agree that the profiling API is not a good way just to get this metadata.

> I don't know about the cost of finalization in .NET, although I assume they are similar. Reading about it doesn't seem to be helping much, since it's the sort of thing that's esoteric enough to fall in to cargo-cult land pretty quickly. .NET does have GC.SuppressFinalize that supposedly removes the penalty, but I'm not immediately clear on if that helps in this case.

> Keeping a set of weak references would solve the problem at a not-too-horrible cost (which I think is what PyPy does, but they can share it with the GC so it's not really overhead).

I think weak references are not worth that effort.

> Honestly though, why in the heck would anyone even want to do this? Is there a use case, or is it just matching compatibility with CPython?

I guess it's just interesting for debug code.



Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.