Re: Dispose patern (was: Re: GC pros and cons)
Thomas Davie schrieb am 28.06.2009 18:07:04:
> On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
> > But a garbage collector must be able to detect an object which
> > memory can / must be released. And for all this, the system has to
> > do some work.
> As must your program do if it keeps track of memory manually. Are you
> betting you can make that less work than a bunch of compiler engineers
> can? Note, this actually isn't a bad bet with GC, but it's not a good
> one either.
But I simply know the business logic and the logic of my program. And often it
is simply a series of:
- Create object
- Use it a little
- Dispose object
And C# has even create something just for this:
using (SomeClass someObject = new SomeClass())
{
// Do something with the object ...
}
(It is simply using creating some kind of try finally with a Dispose Call
inside the finally if I am right.)
So there is simply no need for any complex logic. Of course a Garbage collector
can do a lot of nice stuff up to some graphs stuff to detect some Objects that
simply reference each other but no thread can ever reach them.
And what is also important: The Dispose is not freeing memory. But the Objects
are simply ready for destruction and the GC can free the memory in a simply run
with no big effort.
> That sounds exactly like reference counting and it suffers from all
> the well known problems (like retain cycles). The point here is that
> you don't *want* the developer to have control, the developer (myself
> included) is really really bad at doing this, and introduces a *lot*
> of bugs in the process.
> The option for it of course will keep everyone happy, but that doesn't
> mean it should be encouraged ;)
No, It does not really mean reference counting. Of course it is not good to
dispose an object when there is still a reference on it. (In c# this reference
is still valid but simply points to a disposed object so that all internel
references are "cleared".)
- One big advantage is, that you simply resolve "paths" of object references
with results in less work for the garbage collector.
- another big advantage can be the quicker memory deallocation. The world is
not just "managed code". I am quite sure, that the Developer on a Mac also has
a lot of existing modules he wants to use that allocates memory and so. And if
you wait till dispose() is called by the GC, you could have waisted memory in
that time. (Which the GC couldn't see, because the memory involved was not
managed by the GC)
Maybe it helps a little to clarify:
- Dispose is not deallocating memory! It is just doing the logic required to
make the object ready for destruction. One important part for that is simply
setting references to null.
- Finalize is what is done directly before the destruction (So far that part
was never important for me in all my developing practice)
So the management of the memory is done by the GC, but we simply help the GC
(and keep care of other resources that are not managed)
Hope I was able to clarify this a little. The link to CodeProject also gives
such an overview but I know that it is not of any interest for an objective-c
developer because it only handles managed code / Microsoft .Net Framework. (And
I am really sorry - maybe I simply should have waited till I am much deeper
inside all this Objective-C / Cocoa stuff. Reading all the discussion about the
GC pros and cons simply made me write something, too.)
With kind regards,
Konrad
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Dispose patern (was: Re: GC pros and cons)
On 28 jun 2009, at 10.34, Thomas Davie wrote: Again, IDisposable in C# has nothing to do with early destruction/deallocation of the object. It's purpose to is perform explicit cleanup of external resources, resources not managed by the GC system. For example: file handles, sockets, OS system handles, etc. Calling Dispose() on a C# system does not mark the object for early collection (AFAIK). Oh, personally I would just let GC deal with that -- tie a handle under GC to them, add a finalizer on the handle, and destroy the reference when the handle is destroyed by the GC system. That is not always a valid approach though. If you work with a lot of scarce resources in a short period of time, you might run out of them by outpacing the GC, taking down your app, and possibly the whole system. In general, but in cases such as these in particular, I think it's best to separate memory management from the management of other scarce resources. Some sort of invalidation pattern seems to be the best solution that we know of right now for achieving this. It's great that the GC allows us to not have to deal with the intricate details of managing memory, but I don't think that means that we're off the hook when it comes to thinking about object ownership, and the management of our object graphs. j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dispose patern (was: Re: GC pros and cons)
On 28 Jun 2009, at 19:27, Stephen J. Butler wrote: On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davie wrote: On 28 Jun 2009, at 17:47, Konrad Neitzel wrote: I still have to read much more about the GC used within Objective- C / Cocoa so I am not sure, if I am not writing some kind of "bullshit" from your view: Isn't it possible to simply flag an object to be removed? Is there a dispose pattern in Objective-C? (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a pattern in C#) Something like that would simply more the world together again. That way, the developer has some more control, the GC has less work and all are maybe happy? So is there such an Dispose Pattern in Objective-C using a GC or is there nothing like that? That sounds exactly like reference counting – and it suffers from all the well known problems (like retain cycles). The point here is that you don't *want* the developer to have control, the developer (myself included) is really really bad at doing this, and introduces a *lot* of bugs in the process. The option for it of course will keep everyone happy, but that doesn't mean it should be encouraged ;) Again, IDisposable in C# has nothing to do with early destruction/deallocation of the object. It's purpose to is perform explicit cleanup of external resources, resources not managed by the GC system. For example: file handles, sockets, OS system handles, etc. Calling Dispose() on a C# system does not mark the object for early collection (AFAIK). Oh, personally I would just let GC deal with that -- tie a handle under GC to them, add a finalizer on the handle, and destroy the reference when the handle is destroyed by the GC system. Bob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dispose patern (was: Re: GC pros and cons)
On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davie wrote: > On 28 Jun 2009, at 17:47, Konrad Neitzel wrote: >> I still have to read much more about the GC used within Objective-C / >> Cocoa so I am not sure, if I am not writing some kind of "bullshit" from >> your view: >> >> Isn't it possible to simply flag an object to be removed? Is there a >> dispose pattern in Objective-C? >> (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a >> pattern in C#) >> >> Something like that would simply more the world together again. That way, >> the developer has some more control, the GC has less work and all are maybe >> happy? >> >> So is there such an Dispose Pattern in Objective-C using a GC or is there >> nothing like that? > > That sounds exactly like reference counting – and it suffers from all the > well known problems (like retain cycles). The point here is that you don't > *want* the developer to have control, the developer (myself included) is > really really bad at doing this, and introduces a *lot* of bugs in the > process. > > The option for it of course will keep everyone happy, but that doesn't mean > it should be encouraged ;) Again, IDisposable in C# has nothing to do with early destruction/deallocation of the object. It's purpose to is perform explicit cleanup of external resources, resources not managed by the GC system. For example: file handles, sockets, OS system handles, etc. Calling Dispose() on a C# system does not mark the object for early collection (AFAIK). It still has to pass through the GC like any other object. In fact, disposed objects may still be useful long after they are disposed (perhaps they contain connection statistics, fetched data, or something else). Objective-C already has an informal IDisposable. Any class with a "close" message is essentially doing the same thing. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dispose patern (was: Re: GC pros and cons)
On 28 Jun 2009, at 17:47, Konrad Neitzel wrote: Thomas Davie schrieb am 27.06.2009 09:56:31: On 27 Jun 2009, at 01:27, James Gregurich wrote: GC isn't nirvana. it does have its perils and issues, and you have to be aware of them and code around them. You can't just turn it on and some how everything magically works. There is no perfect solution to memory management. I prefer a solution where I manage the dependencies and objects go away in an orderly fashion based on the dependency graph for those objects. Uhhh, you mean a garbage collector? That's exactly what it does -- frees objects when nothing depends on them any more. But a garbage collector must be able to detect an object which memory can / must be released. And for all this, the system has to do some work. As must your program do if it keeps track of memory manually. Are you betting you can make that less work than a bunch of compiler engineers can? Note, this actually isn't a bad bet with GC, but it's not a good one either. I still have to read much more about the GC used within Objective- C / Cocoa so I am not sure, if I am not writing some kind of "bullshit" from your view: Isn't it possible to simply flag an object to be removed? Is there a dispose pattern in Objective-C? (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a pattern in C#) Something like that would simply more the world together again. That way, the developer has some more control, the GC has less work and all are maybe happy? So is there such an Dispose Pattern in Objective-C using a GC or is there nothing like that? That sounds exactly like reference counting – and it suffers from all the well known problems (like retain cycles). The point here is that you don't *want* the developer to have control, the developer (myself included) is really really bad at doing this, and introduces a *lot* of bugs in the process. The option for it of course will keep everyone happy, but that doesn't mean it should be encouraged ;) Bob___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
