Idea: GC and IDisposable

Hi,

I'm sure I'm simplifying things here, but how about if the GC did this to
objects that implement IDisposable:
1. Always Generation 1 (I think that is the correct name)
2. Get aggressive with them:
a. Nuke 'em on a GC.Collect call (or equivalent)
b. Call Dispose on the object.

Yes, I understand that the compiler and the GC doesn't know what IDisposable
is, but surely it is a worthwhile consideration? This garbabe/resource
collection is particularly important in the CF world.

Hilton

Hilton,

This idea doesn't do much, really. It only serves to reward people for
not being aware of the implementation of their designs.

If you are not aware of the lifespans of the objects that you are using,
then that is an error, either in design, or implementation, or the
understanding of the underlying technologies and it should be fixed. If
something implements IDisposable, that should be a huge red flag that tells
the developer "hey, YOU (not the GC) need to pay extra attention to me, as I
am doing something that you want to pay attention to, and not just leave
lying around."


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"Hilton" <nospam@nospam.com> wrote in message
news:fmVJi.580$4V6.357@newssvr14.news.prodigy.net. ..
> Hi,
>
> I'm sure I'm simplifying things here, but how about if the GC did this to
> objects that implement IDisposable:
> 1. Always Generation 1 (I think that is the correct name)
> 2. Get aggressive with them:
> a. Nuke 'em on a GC.Collect call (or equivalent)
> b. Call Dispose on the object.
>
> Yes, I understand that the compiler and the GC doesn't know what
> IDisposable is, but surely it is a worthwhile consideration? This
> garbabe/resource collection is particularly important in the CF world.
>
> Hilton
>
>

Hilton wrote:
> Hi,
>
> I'm sure I'm simplifying things here, but how about if the GC did this to
> objects that implement IDisposable:
> 1. Always Generation 1 (I think that is the correct name)
> 2. Get aggressive with them:
> a. Nuke 'em on a GC.Collect call (or equivalent)
> b. Call Dispose on the object.
>
> Yes, I understand that the compiler and the GC doesn't know what IDisposable
> is, but surely it is a worthwhile consideration? This garbabe/resource
> collection is particularly important in the CF world.
>
> Hilton

The IDisposable interface is intended for the developer to be able to
control the life cycle of an object. That doesn't only mean to kill it
in a predictable way, but sometimes also to keep it alive in a
predictable way.

--
Göran Andersson
_____
http://www.guffa.com

Agreed. Implementing IDisposable is a flag to the consumer, not the GC.
The GC doesn't know or care about IDisposable objects. If it did, then you
would have the issues currently surrounding Finalizers to content with (and
that's the exact reason it's recommended that you implement IDisposable
instead of using a Finalizer).

There's no way to "automate" this process without causing pain for those of
us who like performance or adding the requirement of multiple collection
cycles to release resources.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:eBCqU1u$HHA.4984@TK2MSFTNGP06.phx.gbl...
> Hilton,
>
> This idea doesn't do much, really. It only serves to reward people for
> not being aware of the implementation of their designs.
>
> If you are not aware of the lifespans of the objects that you are
> using, then that is an error, either in design, or implementation, or the
> understanding of the underlying technologies and it should be fixed. If
> something implements IDisposable, that should be a huge red flag that
> tells the developer "hey, YOU (not the GC) need to pay extra attention to
> me, as I am doing something that you want to pay attention to, and not
> just leave lying around."
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard.caspershouse.com
>
> "Hilton" <nospam@nospam.com> wrote in message
> news:fmVJi.580$4V6.357@newssvr14.news.prodigy.net. ..
>> Hi,
>>
>> I'm sure I'm simplifying things here, but how about if the GC did this to
>> objects that implement IDisposable:
>> 1. Always Generation 1 (I think that is the correct name)
>> 2. Get aggressive with them:
>> a. Nuke 'em on a GC.Collect call (or equivalent)
>> b. Call Dispose on the object.
>>
>> Yes, I understand that the compiler and the GC doesn't know what
>> IDisposable is, but surely it is a worthwhile consideration? This
>> garbabe/resource collection is particularly important in the CF world.
>>
>> Hilton
>>
>>
>
>

> The IDisposable interface is intended for the developer to be able to
> control the life cycle of an object. That doesn't only mean to kill it in
> a predictable way, but sometimes also to keep it alive in a predictable
> way.

Exactly. I sure wouldn't like all my Form and Control-derived objects being
disposed on every GC, yet I'm pretty sure they implement IDisposable.

>
> --
> Göran Andersson
> _____
> http://www.guffa.com

On Sep 24, 4:48 pm, Göran Andersson <gu...@guffa.com> wrote:
> The IDisposable interface is intended for the developer to be able to
> control the life cycle of an object. That doesn't only mean to kill it
> in a predictable way, but sometimes also to keep it alive in a
> predictable way.

That was a very well thought out response.

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:e%23UVlTv$HHA.2004@TK2MSFTNGP06.phx.gbl...
> Agreed. Implementing IDisposable is a flag to the consumer, not the GC.
> The GC doesn't know or care about IDisposable objects. If it did, then
> you would have the issues currently surrounding Finalizers to content with
> (and that's the exact reason it's recommended that you implement
> IDisposable instead of using a Finalizer).
>
> There's no way to "automate" this process without causing pain for those
> of us who like performance or adding the requirement of multiple
> collection cycles to release resources.

Sure there is. How would you call Dispose? You'd call it on an object -
right? That means that it would not be GC'd (yet) since you are holding a
reference to it, so everything works just fine as it always has. Now when
this object can be GC'd (no refs etc), then 'my' logic kicks in, disposes
the object and frees the memory ***IF*** it hasn't already been disposed.
It's just a safety net, not a new paradigm.

Your code is not affected, you can continue to optimize, but the GC will
dispose of any objects that need to be disposed, but weren't. Sounds good
to me.

Hilton

"Göran Andersson" <guffa@guffa.com> wrote in message
news:eUOZsSv$HHA.3848@TK2MSFTNGP05.phx.gbl...
> The IDisposable interface is intended for the developer to be able to
> control the life cycle of an object. That doesn't only mean to kill it in
> a predictable way, but sometimes also to keep it alive in a predictable
> way.

Just holding a reference to it will keep it alive as it always has.

Hilton

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:eBCqU1u$HHA.4984@TK2MSFTNGP06.phx.gbl...
> Hilton,
>
> This idea doesn't do much, really. It only serves to reward people for
> not being aware of the implementation of their designs.
>
> If you are not aware of the lifespans of the objects that you are
> using, then that is an error, either in design, or implementation, or the
> understanding of the underlying technologies and it should be fixed. If
> something implements IDisposable, that should be a huge red flag that
> tells the developer "hey, YOU (not the GC) need to pay extra attention to
> me, as I am doing something that you want to pay attention to, and not
> just leave lying around."

That's a great argument for using free/malloc instead of a GC. A GC is
there so that you don't have to worry about this stuff. All we've done is
reduce the set of objects we're watching from "all" to "some". I'm saying
that by adding a "if (!Disposed) o.Dispose()" would solve a lot of bug and
memory leaks - we see them here all the time. I see it in the CF too.

Hilton

But now the GC has to track every object that you've called Dispose on. And
how does it know what resources it holds? Should it keep track of all
object held within some class that called Dispose? What if those objects
have a Dispose method? Should the GC call it that too? What if it's
already been called? Now we need to track that. How about it's internal
objects? Track them too? It gets real ugly real fast. The metadata the GC
would have to hold would be large and the time required to Collect would
lengthen substantially. It's a lot easier, cleaner and certainly faster to
have the one who should know what needs to be Disposed - the application -
handle it.

The GC already spends more time than I'd like doing stuff I can't control.
The last thing I need is it doing more.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com



"Hilton" <nospam@nospam.com> wrote in message
news:6l%Ji.35641$RX.5162@newssvr11.news.prodigy.ne t...
> "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
> news:e%23UVlTv$HHA.2004@TK2MSFTNGP06.phx.gbl...
>> Agreed. Implementing IDisposable is a flag to the consumer, not the GC.
>> The GC doesn't know or care about IDisposable objects. If it did, then
>> you would have the issues currently surrounding Finalizers to content
>> with (and that's the exact reason it's recommended that you implement
>> IDisposable instead of using a Finalizer).
>>
>> There's no way to "automate" this process without causing pain for those
>> of us who like performance or adding the requirement of multiple
>> collection cycles to release resources.
>
> Sure there is. How would you call Dispose? You'd call it on an object -
> right? That means that it would not be GC'd (yet) since you are holding a
> reference to it, so everything works just fine as it always has. Now when
> this object can be GC'd (no refs etc), then 'my' logic kicks in, disposes
> the object and frees the memory ***IF*** it hasn't already been disposed.
> It's just a safety net, not a new paradigm.
>
> Your code is not affected, you can continue to optimize, but the GC will
> dispose of any objects that need to be disposed, but weren't. Sounds good
> to me.
>
> Hilton
>
>