[Mono-dev] Why does .NET object lifetime not extend into an instance method call?

[Diego Frata]

mo actually is this.mo, so you do have a reference for this.


Diego Frata
diego.frata at gmail.com


On Fri, Aug 24, 2012 at 5:47 PM, Lepisto, Stephen P <
stephen.p.lepisto at intel.com> wrote:

>  Am I wrong in thinking that in****
>
> ** **
>
>    void Problem() { mo.doSomething(); }****
>
> ** **
>
> "mo" is contained within the context of the method body of Problem() and
> therefore cannot be disposed of until the method body of Problem() has done
> execution.  This means that "mo" will continue to live for the life of the
> call to doSomething() because the Problem() method body holds onto "mo"
> until after doSomething() returns.****
>
> ** **
>
> ** **
>
> *From:* mono-devel-list-bounces at lists.ximian.com [mailto:
> mono-devel-list-bounces at lists.ximian.com] *On Behalf Of *David Jeske
> *Sent:* Friday, August 24, 2012 1:27 PM
> *To:* Jonathan Pryor
> *Cc:* mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] Why does .NET object lifetime not extend into
> an instance method call?****
>
> ** **
>
> On Fri, Aug 24, 2012 at 10:50 AM, Jonathan Pryor <jonpryor at vt.edu> wrote:*
> ***
>
> > It seems this could happen in more cases than just PInvoke. This seems
> to allow a finalizer to run before an object is "done being used" anytime
> the object instance is not stored. (i.e. inside a statement of the form
> "new Foo().Method();") If the finalizer triggers an IDispose pattern, this
> could cause a managed resource to be torn down before it's done being used
> as well.****
>
> ** **
>
> The managed resource can't be disposed before it's done being used AS LONG
> AS the GC knows about all uses of the managed resource.****
>
> ** **
>
> ... snip ... ****
>
> ** **
>
> The real problem is that the GC doesn't know anything about native code,
> and thus can't ensure that no native code is using the resource.****
>
>  ** **
>
> Thanks very mych for the detailed reply. It seems to me there is a race
> that has nothing to do with native code. Consider this example..****
>
> ** **
>
> class Foo : IDisposable {****
>
>    ManagedObject mo = new ManagedObject();****
>
> ** **
>
>    ~Foo() { this.Dispose(); }****
>
>    public void Dispose() {****
>
>        if (mo != null) {****
>
>           try {mo.Dispose();} finally { mo = null; }****
>
>        }****
>
>    } ****
>
> ** **
>
>    void Problem() { mo.doSomething(); }****
>
> ** **
>
>    static void Main() { new Foo().Problem(); }****
>
> } ****
>
>
> If I understand the MS.NET article, as soon as ms.doSomething enters the
> vcall, "this" is no longer referenced. Which means during
> ManagedObject.DoSomething, Foo could be finalized, and thus Disposed, and
> since the Dispose explicitly Disposes mo, the code would Dispose mo while
> it's still inside mo.doSomething(). Did I miss something?
>
>  ****
>
> > Why isn't this considered a bug in the .NET runtime?****
>
> How would you fix it? The .NET runtime has no way of knowing what native
> code is doing, so short of disassembling the native code ("magic"), what is
> .NET supposed to do?****
>
> ** **
>
> Ohh, I don't think the problem is the way this is handled for native code.
> I think the above interaction in IDisposable seems like a problem too. To
> me this seems like a pre-mature finalization bug caused because "this"
> isn't considered referenced for the entire body of instance methods.****
>
> ** **
>
>  > (2) Does the Mono GC have the same behavior?****
>
> Yes, because there's no other sane behavior.****
>
>   ****
>
> However, this can't be relied upon; Linux supports "precise stack
> marking," which prevents conservative scanning of native stack frames. This
> has the wonderful performance advantage that less memory needs to be
> pinned, allowing the GC to be more efficient:
>
>         http://www.mono-project.com/Generational_GC#Precise_Stack_Marking*
> ***
>
>  ** **
>
> I'm sorry for my naivety. Why does allowing unused function arguments to
> be collected before a function returns have such important effects on
> memory usage? ****
>
>  ****
>
> ** **
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120824/8fe09606/attachment-0001.html>