Re: Dispose pattern (was: Re: GC pros and cons)

[Konrad Neitzel]

Hi Stephen,

thank you very much for taking the time to look at the given link and writing 
this very nice response to me.

Think I was little confused so I mixed a few things that simply should stay 
seperate.
(Managing resources in close() has simply nothing to do GarbageCollection. Some 
activities may help the GC but it is not, what the main discussion was about 
and it is (normaly) not required. And if something is required, there are 
better ways e.g.  collectIfNeeded message gives a hint to the Garbage 
Collector. )

The Garbage Collection Programming Guide from Apple holds a lot of nice 
information and I simply should have readed that before I bothered the Mailling 
List.
Sorry, if I confused anybody and thank you who tried to help me with their time 
and answers.

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: GC pros and cons

[James Gregurich]

you're right.

I do make the assumption that only sane exceptions are  
thrown...meaning subclasses of NSException & std::exception. Certainly  
any code that I control only throws proper exceptions. For C++  
functions, I use exception specifiers. so, if any function throws the  
wrong type of exception, it fails very early in the stack unwinding so  
that I have a good idea of where the problem is.




On Jun 28, 2009, at 7:23 PM, Chris Idou wrote:








From: James Gregurich 

3) I don't allow exceptions of any kind to propagate into alien  
codeparticularly the cocoa runtime.




Given that Objective-C doesn't have declared exceptions (like Java),  
it seems more likely that you "hope" exceptions are not propagated  
into alien code.


Unless that is you are in the unusual situation that you use no  
third party libraries, or you have full and perfect knowledge of  
where and when they might throw an exception.



 Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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/bayoubengalml%40mac.com

This email sent to bayoubenga...@mac.com


___

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 pattern (was: Re: GC pros and cons)

[Stephen J. Butler]

On Sun, Jun 28, 2009 at 10:50 AM, 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.
>
> 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 article does not say what you think it says. Dispose() does not
"flag an object to be removed". It is also not normally the place to
start setting all your instance variables to null. In fact, the only
thing it has to say about what you're asserting is this:

"You should also consider setting any large and expensive managed
objects that you own to null before calling Dispose. This is seldom
necessary, but it can help reduce the lifetime of the object by making
it eligible for garbage collection sooner. Of course, the definition
of large and expensive is subjective, and should be based on
performance profiling and measurement.

If you are creating a value type, you should avoid making it
disposable, and it should never contain unmanaged resources directly."

So, according to your own evidence, the effort put forth to null
instance variables should only be done when performance profiling and
measurement warrants it. Otherwise, it's simply doesn't have a
benefit. And in classes that don't wrap unmanaged resources, you
shouldn't write a Dispose() at all!

Everything else in that article about setting instance variables to
null has to do with breaking Dispose() loops when calling Dispose() on
owned objects. NOT because it makes them collectable faster, or easier
to collect.

Again, Dispose() is only for handling UNMANAGED resources, stuff the
GC doesn't know how to collect or can't collect. And if you want a
Dispose() like handling in Objective-C (just like Java), write a
"close" message and document that it should be called when the user is
done with the object. It gives you just as much benefit as Dispose()
does in C#.

I also challenge your assertion that a bunch of disconnected objects
are easier to collect than an entire graph of connected objects.
Without looking at the actual GC code, I could make an argument either
way. It would be entirely up to the implementation over which gives a
benefit, and GC implementations change all the time.

I have no idea why so many people are hell bent on circumventing the
GC. The biggest reason to use it is because then you don't have to
worry about managing your memory anymore. Yet here you all are,
inventing bogus ways to once again manage the memory! If you can't let
go and allow the system to do its thing, then don't use GC.
___

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)

[Konrad Neitzel]

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

Dispose pattern (was: Re: GC pros and cons)

[Konrad Neitzel]

Hi all!

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.

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?

With kind regards,

Konrad Neitzel

___

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: [bulk]: Re: GC pros and cons

[Konrad Neitzel]

Graham Cox  schrieb am 27.06.2009 05:13:37:

> Using GC may mean you can avoid even that small degree of necessary  
> care, but the ownership rules are straightforward, easily learned and  
> committed to mind, and are hardly arcane or arbitrary - they are  
> simple and logical. I'd really rather deal with that and the odd bug  
> where I forgot something than the performance hit I'm going to take  
> when GC kicks in. I know that this hit is small, but so is the effort  
> required to use retain/release, so it seems to me we are arguing about  
> small stuff here, not big stuff.

> I don't really get why the memory management/ownership rules seem to  
> be so hard for so many people. But I accept that they are, to some. If  
> they are, maybe GC is a godsend to those folk, but for everyone else,  
> I just can't see the big deal.

Hmm. I am new to Objective C and Software development on a mac. I am earning my 
money with software development on windows using Visual Studio / C#.

And in the managed environment. you get much more advantages than just 
something like "If some people cannot learn some basic memory management, then 
maybe something like that is good..." (Sorry, that is, what I mostly read in 
your argument. sorry when I got you wrong)

It simply has nothing to do with care. But there are a few facts:
1) Errors will be done as long as it is possible to do errors. It has nothing 
to do with beeing carefull or not.
2) I want the system to be secure. I don't want to have some kind of trustment 
in people I do not know.  I really like the managed environment, because it 
takes some security related stuff from teh shoulders of the developer.

Of course: All this stuff is not required! The "managed system" is not doing 
anything special. You can make sure, that there are no buffer overflows and no 
access to not initialized objects and all this stuff. But the past simply 
shows, that a lot of developer simply do not care or simply make errors. Just 
have a look at annoced security holes where people use such bugs to stop 
services or even get access to systems.

And the argument, that the GC will take some time when it starts to free memory 
(Which can also be a large hit in the .Net Environment. It simply depends how 
much work the GC has to do to free some memory that could be required): 
What kind of application are we talking about? Is it really a problem to have 
such a short delay?  If such a small delay is not acceptable, maybe the whole 
system is not acceptable and you simply need a RTOS. (And what are you doing to 
make sure, that you do not have such delays? Are you sure, that the calls you 
are using now are completing in the time you are expecting?

Of course I am aware, that this is far away from the main discussion about the 
GC and the behaviour of the GC (Which I do not understand. If an object is no 
longer referenced inside my active code, I do not care when the memory is 
released completly. But I just started to read into objective-C / Cocoa to 
start some development on my iMac, so I think I will catch the discussion some 
time later!) and I am comming with a fully managed environment which is 
something else even if the managed environment has a GC, too. But the point in 
my eyes is, to simplify development and make it more secure.

That is just my small view and I hope it was a little helpfull. Don't be mad at 
me, if I got you or the discussion wrong. And hopefully you will read some more 
from me in the future here. Will take the printed PDFs MemoryMgmt.pdf, 
GarbageCollection.pdf and ObjCRuntimeRef.pdf from the printer now to read them 
in the train next.

With kind regards,

Konrad Neitzel


___

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: GC pros and cons

[Chris Idou]

From: James Gregurich 

> 3) I don't allow exceptions of any kind to propagate into alien 
> codeparticularly the cocoa runtime.



Given that Objective-C doesn't have declared exceptions (like Java), it seems 
more likely that you "hope" exceptions are not propagated into alien code.

Unless that is you are in the unusual situation that you use no third party 
libraries, or you have full and perfect knowledge of where and when they might 
throw an exception.


  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[mmalc Crawford]

On Jun 28, 2009, at 4:40 PM, Michael Ash wrote:


Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further


This article:


is of particular relevance.

If anything is not clear, please send feedback.

mmalc

___

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: GC pros and cons

[Clark Cox]

On Sun, Jun 28, 2009 at 4:32 PM, Quincey
Morris wrote:
> On Jun 28, 2009, at 16:12, Michael Ash wrote:
>
>> Your way sounds sensible, but according to the docs that's not how it is.
>
> We'll have to wait for b.bum to adjudicate, since the docs contradict what
> he said earlier:
>
> On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:
>>
>> When a CF object is created, it is CFRetain()ed and, thus, the collector
>> will ignore it.  If it is then managed entirely through a balanced set of
>> CFRelease() and CFRetain() calls, it'll work just like it does under
>> non-GC.
>>
>> If you call CFMakeCollectable(), that'll effectively balance the
>> CFRetain()
>> at creation while making the collector aware of the object.
>
> His "just like it does" strongly implies that the memory is disposed of
> immediately, unless he meant "just like it does under non-GC, except for the
> timing of disposal".
>
> His "making the collector aware of the object" contradicts the docs, since
> that would be a third thing CFMakeCollectable does.
>
> Of course, it might work the way the docs say in Leopard, and possibly Bill
> was talking about possible future behavior in some possible future Mac OS X.

The collector is always "aware" of CF objects in the same way as it is
aware of Objective-C objects. The difference is that the retain count
that CFRetain/CFRelease manage is still honored under GC. An object
with a non-zero CF retain count is not eligible for collection,
regardless of whether or not there are any other strong references to
it. This allows CF-using code to work  under GC, in much the same way
as it does under retain/release.

Under garbage collection, CFMakeCollectable (and NSMakeCollectable) is
simply an alias for CFRelease, but with an better, more
intention-revealing name. Under retain/release on the other hand,
CF/NSMakeCollectable is a no-op.

This fact can also be used in the other direction. If you have an
Objective-C object that you want to stick around, even if there are no
strong references to it (e.g. if you want to store it in a void*,
perhaps to pass as a callback parameter, or if you want to store it in
an STL container), you can CFRetain it, and the collector will know
that it is a live object, effectively rooting it, until a
corresponding CFRelease (or CFMakeCollectable) decreases its CF-retain
count to zero.

>From the collector's point of view, there is no difference between an
Objective-C object, and a CFType object with a zero retain count.


-- 
Clark S. Cox III
clarkc...@gmail.com
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 28, 2009, at 6:32 PM, Quincey Morris wrote:

On Jun 28, 2009, at 16:12, Michael Ash wrote:
Your way sounds sensible, but according to the docs that's not how  
it is.
We'll have to wait for b.bum to adjudicate, since the docs  
contradict what he said earlier:


bbum is currently on vacation and only answering questions from memory  
because bbum's hard drive done gone and exploded.  I'm sans dev tools  
or source!  (Yes, I find answering questions on cocoa-dev and reading  
source to be vacating.  Go figure).  Thankfully, I lost nothing save  
for a few bad pictures.  All the good ones were fine.


In any case, it entirely depends on the zone of allocation.

MOST of the time, a CF based object will be allocated from the GC zone  
and, thus, the collector will treat it just like any other random CF*  
or NS* based object.


The one key difference between CF* and NS* objects is that CF* objects  
are created CFRetain'ed.  That is, they won't be collected until they  
are explicitly CFRelease'd.


CFMakeCollectible() simply CFRelease()s the object and leaves it up to  
the collector get around to collecting it.


However, CF can have other kinds of allocators than the default one.   
Thus, it is possible to create CF objects that don't follow these  
rules.   But don't do that.


And, as Michael said:


Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further


Absolutely right.   Go do that.

b.bum

___

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: GC pros and cons

[Michael Ash]

On Sun, Jun 28, 2009 at 7:33 PM, Peter Duniho wrote:
> Maybe I'm misreading one, or the other, or both of your messages, but it
> seems to me that what Quincy wrote is in agreement with what you quoted.
>
> In particular, my (admittedly inexperienced) understanding is that an object
> winds up "in the garbage collected zone" when code calls CFMakeCollectable.
>  Conversely, "GC-unaware code" would not, I would think, call
> CFMakeCollectable (that seems like a very "GC-aware" thing to do, right?).

"NULL, kCFAllocatorDefault, and kCFAllocatorSystemDefault specify
allocation from the garbage collection zone.

"By default, all Core Foundation objects are allocated in the garbage
collection zone."

And while we're at it, CFMakeCollectable doesn't do *anything*
magical, all it does is call CFRelease under GC, and assert that the
object is in the right zone. If you know that you're running under GC
and that the object will be in the garbage collected zone, it is
*identical* to CFRelease:

"Better still, though, you can use CFMakeCollectable instead of
CFRelease. CFMakeCollectable calls CFRelease, but has two
supplementary features: first, it halts the program if the object
wasn't allocated in the scanned zone; second, it’s a no-op in a
reference counted environment."

Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further

Mike
___

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: GC pros and cons

[Peter Duniho]

On Jun 28, 2009, at 4:12 PM, Michael Ash wrote:


On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morris wrote:

I think the answer is in Bill's "entirely", above.

Without CFMakeCollectable, the final CFRetain will trigger the  
calling of (a
hypothetical) CFDispose with the traditional timing (i.e.  
immediately, we

assume, somewhat at our peril).

[...] Thus GC-unaware code gets the behavior at CFRelease time that  
it expects

(somewhat at its peril), whether or not it is running in a GC-enabled
environment.


"If the object is in the garbage collected zone, the last CFRelease()
does not immediately free the object, it simply makes it eligible to
be reclaimed by the collector when it is discovered to be
unreachable—that is, once all strong references to it are gone. Thus
as long as the object is still referenced from an object-type instance
variable (that hasn't been marked as__weak), a register, the stack, or
a global variable, it will not be collected."


From the Garbage Collection Programming guide.


Your way sounds sensible, but according to the docs that's not how  
it is.


Maybe I'm misreading one, or the other, or both of your messages, but  
it seems to me that what Quincy wrote is in agreement with what you  
quoted.


In particular, my (admittedly inexperienced) understanding is that an  
object winds up "in the garbage collected zone" when code calls  
CFMakeCollectable.  Conversely, "GC-unaware code" would not, I would  
think, call CFMakeCollectable (that seems like a very "GC-aware" thing  
to do, right?).


I suppose in a scenario where some code is using an object allocated  
by some other code, where that other code has called  
CFMakeCollectable, but the first code is "GC-unaware", that would be  
an exception to the statements made.  But it doesn't seem like an  
important exception to me, because that first code shouldn't be  
assuming ownership or control over the object anyway (i.e. obviously  
it got the object from somewhere else, and it has no reason to believe  
that it holds the last retain on the object, even if that first code  
doesn't know anything about garbage-collection).


If I've somehow misconstrued what either of you wrote, I apologize.   
But as things stand now, I'm not convinced you're in contradiction  
with each other.


Pete___

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: GC pros and cons

[Quincey Morris]

On Jun 28, 2009, at 16:12, Michael Ash wrote:

Your way sounds sensible, but according to the docs that's not how  
it is.


We'll have to wait for b.bum to adjudicate, since the docs contradict  
what he said earlier:


On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:


When a CF object is created, it is CFRetain()ed and, thus, the  
collector
will ignore it.  If it is then managed entirely through a balanced  
set of
CFRelease() and CFRetain() calls, it'll work just like it does under  
non-GC.


If you call CFMakeCollectable(), that'll effectively balance the  
CFRetain()

at creation while making the collector aware of the object.


His "just like it does" strongly implies that the memory is disposed  
of immediately, unless he meant "just like it does under non-GC,  
except for the timing of disposal".


His "making the collector aware of the object" contradicts the docs,  
since that would be a third thing CFMakeCollectable does.


Of course, it might work the way the docs say in Leopard, and possibly  
Bill was talking about possible future behavior in some possible  
future Mac OS X.



___

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: GC pros and cons

[Michael Ash]

On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morris wrote:
> I think the answer is in Bill's "entirely", above.
>
> Without CFMakeCollectable, the final CFRetain will trigger the calling of (a
> hypothetical) CFDispose with the traditional timing (i.e. immediately, we
> assume, somewhat at our peril).
>
> After CFMakeCollectable in a GC-enabled environment, the final CFRetain (if
> there is one, if the retain count was greater than 1 at the time
> CFMakeCollectable was called) will just discard *the* strong reference that
> the retain count was maintaining. This will trigger the calling of (a
> hypothetical) CFFinalize with the usual timing (i.e. when the collector
> runs, after there are no other strong references remaining).
>
> Thus GC-unaware code gets the behavior at CFRelease time that it expects
> (somewhat at its peril), whether or not it is running in a GC-enabled
> environment.

"If the object is in the garbage collected zone, the last CFRelease()
does not immediately free the object, it simply makes it eligible to
be reclaimed by the collector when it is discovered to be
unreachable—that is, once all strong references to it are gone. Thus
as long as the object is still referenced from an object-type instance
variable (that hasn't been marked as__weak), a register, the stack, or
a global variable, it will not be collected."

>From the Garbage Collection Programming guide.

Your way sounds sensible, but according to the docs that's not how it is.

Mike
___

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)

[Joar Wingfors]

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)

[Thomas Davie]

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)

[Stephen J. Butler]

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: GC pros and cons

[Quincey Morris]

On Jun 28, 2009, at 04:39, Michael Ash wrote:


On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:


When a CF object is created, it is CFRetain()ed and, thus, the  
collector
will ignore it.  If it is then managed entirely through a balanced  
set of
CFRelease() and CFRetain() calls, it'll work just like it does  
under non-GC.


If you call CFMakeCollectable(), that'll effectively balance the  
CFRetain()

at creation while making the collector aware of the object.

Thus, no real edge case here (as designed).


Right, but once you do the final CFRelease and the retain count hits
zero, objects in the default zone aren't destroyed, but merely become
eligible for collection. This modifies their lifetimes and may cause
their destruction code to run at a different time and in a different
context. This could conceivably cause trouble for CF containers with
custom callbacks that were built with the assumption that they would
run synchronously with the final CFRelease.


I think the answer is in Bill's "entirely", above.

Without CFMakeCollectable, the final CFRetain will trigger the calling  
of (a hypothetical) CFDispose with the traditional timing (i.e.  
immediately, we assume, somewhat at our peril).


After CFMakeCollectable in a GC-enabled environment, the final  
CFRetain (if there is one, if the retain count was greater than 1 at  
the time CFMakeCollectable was called) will just discard *the* strong  
reference that the retain count was maintaining. This will trigger the  
calling of (a hypothetical) CFFinalize with the usual timing (i.e.  
when the collector runs, after there are no other strong references  
remaining).


Thus GC-unaware code gets the behavior at CFRelease time that it  
expects (somewhat at its peril), whether or not it is running in a GC- 
enabled environment.



___

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)

[Thomas Davie]

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

Re: GC pros and cons

[Michael Ash]

On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:
> On Jun 27, 2009, at 8:38 PM, Michael Ash wrote:
>>
>> (And I only say "almost" because I can only assume there's a corner
>> case out there somewhere with CoreFoundation-using code, since CF
>> objects are also garbage collected, but I am not actually aware of
>> any.)
>
> When a CF object is created, it is CFRetain()ed and, thus, the collector
> will ignore it.  If it is then managed entirely through a balanced set of
> CFRelease() and CFRetain() calls, it'll work just like it does under non-GC.
>
> If you call CFMakeCollectable(), that'll effectively balance the CFRetain()
> at creation while making the collector aware of the object.
>
> Thus, no real edge case here (as designed).

Right, but once you do the final CFRelease and the retain count hits
zero, objects in the default zone aren't destroyed, but merely become
eligible for collection. This modifies their lifetimes and may cause
their destruction code to run at a different time and in a different
context. This could conceivably cause trouble for CF containers with
custom callbacks that were built with the assumption that they would
run synchronously with the final CFRelease.

(Of course they should not *have* such assumptions, but that doesn't
mean they won't.)

Or did I misunderstand something?

Mike
___

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: GC pros and cons

[Rob Keniger]

On 28/06/2009, at 8:45 AM, Jeff Johnson wrote:

One con of adopting GC on Leopard is that your app is quite likely  
to spam the console log profusely, making a small but technically- 
minded and vocal minority of your users very angry with you. >, dupe of , presumably never to be fixed on  
Leopard.



You can stop this log spew with the code contained in this Xcode plugin:

http://github.com/0xced/quietxcode/tree/master

The plug-in prevents Xcode from spewing these error messages but you  
can use the same code in your own app to do it too.


--
Rob Keniger



___

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: GC pros and cons

[Bill Bumgarner]

On Jun 27, 2009, at 8:38 PM, Michael Ash wrote:

(And I only say "almost" because I can only assume there's a corner
case out there somewhere with CoreFoundation-using code, since CF
objects are also garbage collected, but I am not actually aware of
any.)


When a CF object is created, it is CFRetain()ed and, thus, the  
collector will ignore it.  If it is then managed entirely through a  
balanced set of CFRelease() and CFRetain() calls, it'll work just like  
it does under non-GC.


If you call CFMakeCollectable(), that'll effectively balance the  
CFRetain() at creation while making the collector aware of the object.


Thus, no real edge case here (as designed).

b.bum

___

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: GC pros and cons

[Michael Ash]

On Sat, Jun 27, 2009 at 7:27 PM, Bill Bumgarner wrote:
> On Jun 27, 2009, at 6:05 PM, Nick Zitzmann wrote:
>>
>> That, and 64-bit GC apps allocate a whopping 32 GB of VM on startup on
>> Leopard, which might scare a few people that (1) watch Activity Monitor like
>> a hawk, and (2) think that VM == swap. Most people won't notice, though.
>
> It actually isn't 32GB Of VM, even.  The collector reserves 32GB of
> contiguous addresses, which shows up as VM in Activity Monitor.   None of
> the pages are touched, though, so it is -- as you note -- completely
> innocuous.
>
> But hard to explain, which is a well understood problem and steps have been
> taken to improve the situation.

But that's what VM means: address space. So Activity Monitor is
correct to show it, it's just that users interpret the number
incorrectly. I think the main solution here is education. It's not
like the garbage collector is going to be the only piece of code out
there taking advantage of 64-bit addressing by allocating huge swaths
of address space for their own uses.

Improving things on the OS side sounds like a good idea as long as it
doesn't make Activity Monitor less useful for people who know what the
numbers mean

Mike
___

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: GC pros and cons

[Michael Ash]

On Sat, Jun 27, 2009 at 4:57 PM, James Gregurich wrote:
>
> Bill,
>
> If you guys are going to some day make that statement the law, then please
> keep in mind that whatever you do has to operate with cross platform C++
> code using standard memory management techniques. Many of us have to deal
> with other unix systems and Windows. We need this stuff to all cleanly
> interoperate with standard code.

I wouldn't worry too much about it. It's pretty evident from the
fundamental design of the GC that allowing existing pure C/C++ code to
run unchanged was a top priority, and indeed they have almost
completely succeeded at this.

(And I only say "almost" because I can only assume there's a corner
case out there somewhere with CoreFoundation-using code, since CF
objects are also garbage collected, but I am not actually aware of
any.)

Mike
___

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: GC pros and cons

[James Gregurich]

I figured the details out and taught my staff to use the techniques.  
it isn't that hard. I learned what I needed to know from the objc 2.0  
manual and a little bit of trial and error.


The critical thing to watch are the exceptions since those are  
incompatible in legacy mode. You just have to understand that a C++  
exception won't trip the objc catch machinery and an objc exception  
won't trip the C++ catch machinery. Once you understand that, you  
watch for things, such as @synchronized that rely on those mechanisms  
to function correctly.


I myself didn't hit the @sychronized problem because I don't use  
@synchronize. But, if I had, it would have been pretty obvious if the  
backtrace showed the app was stuck in a a lock in the @synchronized  
after a C++ exception occurred.


I like C++. I find it an incredibly useful language. I like the  
mentality behind the design of C++ & STL. I'm capable of using it  
quite effectively.  So, that is the tool I use. It isn't perfect, but  
I have never seen a developer tool that is perfect.


If you don't like C++ or it isn't an option for you for some reason,  
then my technique isn't for you.



BTW: keep in mind that the exception gotchas go away on iphone & 64  
bit MacOSX. In a few years, once leopard and 32 bit macs are mostly  
retired in the marketplace, one can remove the macros and just catch  
NSException pointers directly. kudos to the objc 2.0 guys for adopting  
the C++ exception system.



Here are the macros if you want to see them. I need to adjust them for  
iphone, but I''l deal with that once I actually start building iphone  
products.



#ifdef __OBJC__
#ifndef __LP64__

#define OBJC_EXCEPTION_TRY @try {
#define OBJC_EXCEPTION_CATCH } @catch(id theExcpPtr) { throw  
theExcpPtr;}

#define OBJC_EXCEPTION_CATCH_IGNORE } @catch(id theExcpPtr) {}

#else

#define OBJC_EXCEPTION_TRY
#define OBJC_EXCEPTION_CATCH
#define OBJC_EXCEPTION_CATCH_IGNORE

#endif
#endif





an example of using them


-(void)writeLogToFile
{
boost::mutex::scoped_lock tmpLock(statFileWriteMutex);

OBJC_EXCEPTION_TRY
[mIndexedDocumentPathsAndTimesSPtr.get()  
writeToFile:mLogPathSPtr.get() atomically:YES];
[mFailedIndexedDocumentPathsAndTimesSPtr.get()  
writeToFile:mFailedLogPathSPtr.get() atomically:YES];

OBJC_EXCEPTION_CATCH
}






On Jun 27, 2009, at 4:39 PM, Greg Guerin wrote:


James Gregurich wrote:

1) I have convenience macros that @catch and throw NSExceptions for  
the legacy 32 bit environment. I don't allow legacy objc exceptions  
to propagate out of code blocks.


2) I don't use @synchronize. I use boost::thread::mutex so that I  
have one consistent, standard locking API throughout my codebase.  
good point on @synchronize. I'll be careful to watch out for it.


3) I don't allow exceptions of any kind to propagate into alien  
codeparticularly the cocoa runtime.


basically, my general approach is to map objc concepts and  
idiosyncrasies into the C++ environmentmaking use of the useful  
features of C++ to solve some of the problems with cocoa  
development. I've been quite happy with the results in general.



Is there a way for other developers to use your approach, or do they  
have to reinvent it for themselves?  Are the rules and restrictions  
written down (e.g. "Don't use @synchronized")?  Better yet, are the  
restrictions enforceable at compilation?  Are all the macros,  
classes, and dependencies (e.g. boost) available in a single  
location?  Are there risks of ad hoc incompatibilities arising due  
to multiple reinvention (assuming each developer is expected to  
reinvent)?


I ask this in all honesty, with no intent of sarcasm or irony.  Even  
if I personally have no intention of using it, it seems to me that  
any approach is valuable mainly to the extent others can use it  
without having to recreate it from scratch, without causing  
compatibility problems.  Otherwise it's just an individual  
productivity tactic, and any experienced developer probably already  
has plenty of those to work from.


Speaking from my own experience, one person's productivity tactic  
can be another person's worst nightmare.  One early example: the  
source for the original Bourne shell.  It was written with Pascal- 
like (or shell-like) macros that redefined if/else, loops, blocks,  
etc.  For example, C code "if (x) { ... }" would be written as "IF x  
THEN ... FI", where IF, THEN, FI etc. are all macros.  While I can  
appreciate the cleverness of this, it was one of the worst things to  
maintain I've ever experienced.  This did not make the shell itself  
any less useful or powerful: it was a great improvement over its  
predecessor, and I did plenty of things with it's extended  
capabilities.  It just made it horrible to have to fix bugs in it,  
or, far worse, add new capabilities.


It seems to me one advantage of the current GC is it's a documented 

Re: GC pros and cons

[Greg Guerin]

James Gregurich wrote:

1) I have convenience macros that @catch and throw NSExceptions for  
the legacy 32 bit environment. I don't allow legacy objc exceptions  
to propagate out of code blocks.


2) I don't use @synchronize. I use boost::thread::mutex so that I  
have one consistent, standard locking API throughout my codebase.  
good point on @synchronize. I'll be careful to watch out for it.


3) I don't allow exceptions of any kind to propagate into alien  
codeparticularly the cocoa runtime.


basically, my general approach is to map objc concepts and  
idiosyncrasies into the C++ environmentmaking use of the useful  
features of C++ to solve some of the problems with cocoa  
development. I've been quite happy with the results in general.



Is there a way for other developers to use your approach, or do they  
have to reinvent it for themselves?  Are the rules and restrictions  
written down (e.g. "Don't use @synchronized")?  Better yet, are the  
restrictions enforceable at compilation?  Are all the macros,  
classes, and dependencies (e.g. boost) available in a single  
location?  Are there risks of ad hoc incompatibilities arising due to  
multiple reinvention (assuming each developer is expected to reinvent)?


I ask this in all honesty, with no intent of sarcasm or irony.  Even  
if I personally have no intention of using it, it seems to me that  
any approach is valuable mainly to the extent others can use it  
without having to recreate it from scratch, without causing  
compatibility problems.  Otherwise it's just an individual  
productivity tactic, and any experienced developer probably already  
has plenty of those to work from.


Speaking from my own experience, one person's productivity tactic can  
be another person's worst nightmare.  One early example: the source  
for the original Bourne shell.  It was written with Pascal-like (or  
shell-like) macros that redefined if/else, loops, blocks, etc.  For  
example, C code "if (x) { ... }" would be written as "IF x THEN ...  
FI", where IF, THEN, FI etc. are all macros.  While I can appreciate  
the cleverness of this, it was one of the worst things to maintain  
I've ever experienced.  This did not make the shell itself any less  
useful or powerful: it was a great improvement over its predecessor,  
and I did plenty of things with it's extended capabilities.  It just  
made it horrible to have to fix bugs in it, or, far worse, add new  
capabilities.


It seems to me one advantage of the current GC is it's a documented  
and more or less standardardized set of rules and behaviors that any  
developer can use, and can also deploy in reusable libraries.  A  
given library may be GC-only, GC-capable, or GC-incompatible, but  
there is still a way to specify this for a library, and it is  
enforced by the tools.


Also, GC works without requiring C++.  There may be reasons why C++  
isn't used in a particular situation, or can't be used, so the fact  
that your approach seems to require C++ automatically precludes it  
from those situations.


  -- GG

___

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: GC pros and cons

[Bill Bumgarner]

On Jun 27, 2009, at 5:45 PM, Jeff Johnson wrote:
One con of adopting GC on Leopard is that your app is quite likely  
to spam the console log profusely, making a small but technically- 
minded and vocal minority of your users very angry with you. >, dupe of , presumably never to be fixed on  
Leopard.


Just something to keep in mind.


Yup. Pain in the $&$&#&@#...@#!)$.  Sorry.   As long as it is sourced  
from the same bug as the log spam caused by Xcode, it is one of the  
rare resurrection errors that is noisy, by harmless.


Fixed in Snow Leopard.

b.bum

___

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: GC pros and cons

[Bill Bumgarner]

On Jun 27, 2009, at 6:05 PM, Nick Zitzmann wrote:
That, and 64-bit GC apps allocate a whopping 32 GB of VM on startup  
on Leopard, which might scare a few people that (1) watch Activity  
Monitor like a hawk, and (2) think that VM == swap. Most people  
won't notice, though.


It actually isn't 32GB Of VM, even.  The collector reserves 32GB of  
contiguous addresses, which shows up as VM in Activity Monitor.   None  
of the pages are touched, though, so it is -- as you note --  
completely innocuous.


But hard to explain, which is a well understood problem and steps have  
been taken to improve the situation.


b.bum

___

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: GC pros and cons

[Nick Zitzmann]

On Jun 27, 2009, at 4:45 PM, Jeff Johnson wrote:

One con of adopting GC on Leopard is that your app is quite likely  
to spam the console log profusely, making a small but technically- 
minded and vocal minority of your users very angry with you. >, dupe of , presumably never to be fixed on  
Leopard.



That, and 64-bit GC apps allocate a whopping 32 GB of VM on startup on  
Leopard, which might scare a few people that (1) watch Activity  
Monitor like a hawk, and (2) think that VM == swap. Most people won't  
notice, though.


Nick Zitzmann


___

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: GC pros and cons

[Jeff Johnson]

On Jun 27, 2009, at 9:28 AM, Bill Bumgarner wrote:

- GC applications are less crash prone than non-GC applications  
(yes, really -- Xcode's crash frequency has dropped significantly in  
the move from non-GC to GC, for example).


One con of adopting GC on Leopard is that your app is quite likely to  
spam the console log profusely, making a small but technically-minded  
and vocal minority of your users very angry with you. >, dupe of , presumably never to be fixed on  
Leopard.


Just something to keep in mind.

-Jeff

___

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: GC pros and cons

[Clark Cox]

On Sat, Jun 27, 2009 at 1:57 PM, James Gregurich wrote:
>
> Bill,
>
> If you guys are going to some day make that statement the law, then please
> keep in mind that whatever you do has to operate with cross platform C++
> code using standard memory management techniques. Many of us have to deal
> with other unix systems and Windows. We need this stuff to all cleanly
> interoperate with standard code.

Objective-C GC *already* works with cross platform C++ code. Just
CFRetain() your ObjC object before handing it off to something that
doesn't understand GC (such as an STL container, or as a generic void*
stored in unscanned memory, etc.) and CFRelease() it after removing
it.

I have a decent amount of (old) Objective-C++ code that does just this
(e.g. storing Obj-C objects in shared_ptr), and I had nothing to do in
order to get it to work under GC.

-- 
Clark S. Cox III
clarkc...@gmail.com
___

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: GC pros and cons

[James Gregurich]

Bill,

If you guys are going to some day make that statement the law, then  
please keep in mind that whatever you do has to operate with cross  
platform C++ code using standard memory management techniques. Many of  
us have to deal with other unix systems and Windows. We need this  
stuff to all cleanly interoperate with standard code.



On Jun 27, 2009, at 7:28 AM, Bill Bumgarner wrote:



- It is the recommended way.   All new Cocoa applications should be  
developed using GC.   The primary reasoning is two fold and  
delineated in the next two points.




___

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: GC pros and cons

[James Gregurich]

1) I have convenience macros that @catch and throw NSExceptions for  
the legacy 32 bit environment. I don't allow legacy objc exceptions to  
propagate out of code blocks.


2) I don't use @synchronize. I use boost::thread::mutex so that I have  
one consistent, standard locking API throughout my codebase. good  
point on @synchronize. I'll be careful to watch out for it.


3) I don't allow exceptions of any kind to propagate into alien  
codeparticularly the cocoa runtime.


basically, my general approach is to map objc concepts and  
idiosyncrasies into the C++ environmentmaking use of the useful  
features of C++ to solve some of the problems with cocoa development.  
I've been quite happy with the results in general.





On Jun 26, 2009, at 9:27 PM, Michael Ash wrote:


Normally this would be a silly nitpick, but given the context of the
discussion, I think it's important to mention.

Your code is *not* completely exception-safe in Objective-C++ on the
Mac 32-bit runtime.

On this runtime (but fortunately not on the "modern" runtime found on
the iPhone and 64-bit processes on the Mac) the Objective-C exception
model is *not* unified with the C++ exception model. This means that
throwing an Objective-C exception through this code will not invoke
the objects' destructors and thus will not deallocate your resource.

Now, Objective-C exceptions are fairly rare and most Cocoa programmers
treat them as programming errors to be fixed rather than runtime
errors to be handled, but it's still something that ought to be kept
in mind.

The same goes for throwing C++ exceptions through Objective-C code.
Objective-C doesn't have destructors, but for example you will not
unlock the lock held in a @synchronized block, and various other
things can go wrong. In general, you should keep things well separated
and just not allow exceptions to be thrown through code from the
"other" language.

Mike
___

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/bayoubengalml%40mac.com

This email sent to bayoubenga...@mac.com


___

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: GC pros and cons

[Bill Bumgarner]

There has been enough signal in this thread that I haven't asked for  
it to be ended, but it is rapidly spiraling the bowl.  Specifically,  
the last dozen or so messages -- mine included -- have been a rehash  
of the same points.  "I like GC" / "I don't like GC" / "GC is non- 
deterministic" / "Non-GC is non-deterministic, too" / etc.


There are a number of advantages to using GC vs. non GC that haven't  
really been mentioned.


- It is the recommended way.   All new Cocoa applications should be  
developed using GC.   The primary reasoning is two fold and delineated  
in the next two points.


- GC applications are less crash prone than non-GC applications (yes,  
really -- Xcode's crash frequency has dropped significantly in the  
move from non-GC to GC, for example).  One of the most common crashes  
in Cocoa applications is related to over-releasing of objects or using  
dangling references.   GC doesn't eliminate crashes, but it certainly  
mitigates this particularly common ones.


- GC applications scale better across multi-core for multiple  
reasons.  Some are obvious;  assignment takes ownership of an object  
atomically in GC while under non-GC, ownership can only happen through  
a non-atomic call to -retain which has to be made atomic through the  
use of locks and, often, exception handlers.  Not so obvious, though,  
is that the collector has a great deal of knowledge about the  
connectivity of your app's object graph and this knowledge can be  
used-- and is being used somewhat in Leopard and much more so in Snow  
Leopard -- to further optimize allocation and reclamation.


The bottom line is that GC offers Apple the opportunity for  
significantly greater whole system optimization opportunities than non- 
GC.   Over time, GC'd applications will get faster -- already have --  
for free.   This is just like CoreData.Clients of CoreData got a  
major performance bump by simply running their app on Leopard.


GC also offers significantly better hooks for analyzing memory usage  
and debugging leaks (yes, leaks in GC do occur) and you can expect  
this to be reflected in the power / feature set of the higher level  
analysis tools such as Instruments.


Finally, GC often improves developer productivity.   Fewer lines of  
code, simpler patterns, etc


Bottom line, though, is what best serves the needs of your customers.

If you feel strongly that you can get your product to market faster,  
penetrate more markets, with better quality, and more refined features  
by using non-GC, then go for it.   Obviously, if you are targeting the  
iPhone, you have to use non-GC.


b.bum
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 27, 2009, at 9:22 AM, WT wrote:
I'm curious now... Is that an "in principle" statement, or has it  
happened to a project that you know of? If the latter, can you  
elaborate a little on the nature of the project, as in what it was  
about it that outran the gc?


This is well covered in the archives.

To summarize: if you have a tight loop that is allocating tons of  
extremely short lived objects, you can get into a situation where the  
collector can't keep up.   This is largely fixed in Snow Leopard,  
though it s still possible.


b.bum

___

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: GC pros and cons

[WT]

On Jun 27, 2009, at 4:09 PM, Michael Ash wrote:


It's *hard* to outrun it and run out of memory, but
it can be done.


I'm curious now... Is that an "in principle" statement, or has it  
happened to a project that you know of? If the latter, can you  
elaborate a little on the nature of the project, as in what it was  
about it that outran the gc?


Wagner
___

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: GC pros and cons

[Michael Ash]

On Sat, Jun 27, 2009 at 8:17 AM, Thomas Davie wrote:
>  If you're worried about running
> out of space because the collector is lazy, then all you need to know is
> that as soon as you get to the "oh shit, no memory" stage, the collector
> runs and frees some more up (unless there really is none to free up).

And once again, no it doesn't. Apple's collector does not trigger on
allocation errors. It's *hard* to outrun it and run out of memory, but
it can be done.

Mike
___

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: GC pros and cons

[Graham Cox]

On 27/06/2009, at 8:58 PM, WT wrote:

I don't think they are hard to understand, or even apply, at all. I  
just extrapolated - and, admittedly, did so without having the  
benefit of experience - that on very large problems, they would  
almost always cause a maintenance nightmare. Your 500+-class,  
millions-of-lines project shows that I was wrong in making that  
assumption. Not the first time that I make a fool of myself in  
public. :)



Not at all.

I'm not saying using retain/release doesn't require care - it does.  
Probably more so than GC. My point is that a bad design is a bad  
design (and we all make them - I just spent a day rewriting some stuff  
I threw together a few months ago that sucks so hard it was just as  
well it was in my private stuff and not on my public washing-line!)  
and using GC to help cover up the effects of a bad design (e.g. retain  
cycles, which arise because ownership wasn't clearly established by  
the design) is not a good thing. GC can't turn a bad design into a  
good one - but I do have a suspicion that it sometimes gets used that  
way.


Just my 2¢ worth, and I'm sure that's all it's worth... ;-)

--Graham


___

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: GC pros and cons

[Klaus Backert]

On 27. Jun 2009, at 14:17, Thomas Davie wrote:


Now I'm confused, because other people said, GC frees objects  
*when* nothing depends on them any more *or* at some point later in  
time. By the way, it would be different, if you said "if" instead  
of "when", but then, I think, you would have no point in the  
ongoing discussion.


Why is this a problem?


It's not a problem for me (and I didn't say so).

Nothing depends on the objects, and hence nothing can see when  
they're actually collected.  If you're worried about running out of  
space because the collector is lazy


I'm not worried about this.

, then all you need to know is that as soon as you get to the "oh  
shit, no memory" stage, the collector runs and frees some more up  
(unless there really is none to free up).


All you're doing by keeping track of the dependancy graph yourself  
is reinventing the wheel


I'm not reinventing the wheel, I use simple retain/release based  
memory management -- and after all these years it *is* simple for me.


-- lots of people have put a lot of research into how to keep track  
of those dependancies fast, and in a way that frees up memory  
quickly and efficiently.


Is it correct reading your answer as "wether objects are freed *when*  
nothing depends on them any more *or* at some point later in time --  
it does *not* matter"?


Still open question:
With GC are objects freed *when* they are used any more *or* at some  
point later in time?


And if it doesn't matter, doesn't it really matter in *all* cases?

By the way, I won't start using GC now because I'm in the midst of a  
project I started without GC. A "monster" :-) dependency graph inside  
is built using OpenSceneGraph, which has its own memory management  
mechanism.


Klaus

___

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: GC pros and cons

[Thomas Davie]

On 27 Jun 2009, at 14:04, Klaus Backert wrote:



On 27. Jun 2009, at 09:54, Thomas Davie wrote:



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.


Now I'm confused, because other people said, GC frees objects *when*  
nothing depends on them any more *or* at some point later in time.  
By the way, it would be different, if you said "if" instead of  
"when", but then, I think, you would have no point in the ongoing  
discussion.


Why is this a problem?  Nothing depends on the objects, and hence  
nothing can see when they're actually collected.  If you're worried  
about running out of space because the collector is lazy, then all you  
need to know is that as soon as you get to the "oh shit, no memory"  
stage, the collector runs and frees some more up (unless there really  
is none to free up).


All you're doing by keeping track of the dependancy graph yourself is  
reinventing the wheel -- lots of people have put a lot of research  
into how to keep track of those dependancies fast, and in a way that  
frees up memory quickly and efficiently.


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: GC pros and cons

[WT]

On Jun 27, 2009, at 5:11 AM, Graham Cox wrote:

I don't really get why the memory management/ownership rules seem to  
be so hard for so many people. But I accept that they are, to some.  
If they are, maybe GC is a godsend to those folk, but for everyone  
else, I just can't see the big deal.


I don't think they are hard to understand, or even apply, at all. I  
just extrapolated - and, admittedly, did so without having the benefit  
of experience - that on very large problems, they would almost always  
cause a maintenance nightmare. Your 500+-class, millions-of-lines  
project shows that I was wrong in making that assumption. Not the  
first time that I make a fool of myself in public. :)


Wagner
___

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: GC pros and cons

[Thomas Davie]

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.


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: GC pros and cons

[Michael Ash]

On Fri, Jun 26, 2009 at 10:24 PM, James Gregurich wrote:
> hehe. oh yes they do.  You can put any TYPE you want in shared_ptr<>.  If you 
> want to put a posix file descriptor in it, just use close() as the custom 
> deleter. works great. In fact, I guard SQLite db handles with shared_ptr.
>
> Here is how you do it:
>
>    std::string tmpDbName("test.db");
>    sqlite3* tmpDbPtr = NULL;
>    boost::shared_ptr tmpDbSPtr;
>    int tmpResult = sqlite3_open_v2(tmpDbName.c_str(), &tmpDbPtr, 
> SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE  | SQLITE_OPEN_NOMUTEX, 
> statVSNamePtr);
>
>    if(tmpResult != SQLITE_OK)
>    {
>        //handle error
>        return;
>    }
>
>    tmpDbSPtr.reset(tmpDbPtr, sqlite3_close);
>
>
> this code is completely exception safe and won't leak the db handle under any 
> circumstances.

Normally this would be a silly nitpick, but given the context of the
discussion, I think it's important to mention.

Your code is *not* completely exception-safe in Objective-C++ on the
Mac 32-bit runtime.

On this runtime (but fortunately not on the "modern" runtime found on
the iPhone and 64-bit processes on the Mac) the Objective-C exception
model is *not* unified with the C++ exception model. This means that
throwing an Objective-C exception through this code will not invoke
the objects' destructors and thus will not deallocate your resource.

Now, Objective-C exceptions are fairly rare and most Cocoa programmers
treat them as programming errors to be fixed rather than runtime
errors to be handled, but it's still something that ought to be kept
in mind.

The same goes for throwing C++ exceptions through Objective-C code.
Objective-C doesn't have destructors, but for example you will not
unlock the lock held in a @synchronized block, and various other
things can go wrong. In general, you should keep things well separated
and just not allow exceptions to be thrown through code from the
"other" language.

Mike
___

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: GC pros and cons

[Graham Cox]

On 27/06/2009, at 11:20 AM, WT wrote:

2) Stick to retain/release and have to maintain a potentially  
extremely complicated object graph, with potentially large and  
interlocking retain cycles?



In practice this isn't the bogeyman that people (particularly newbies)  
tend to assume. I'd say my current app was reasonably large and  
complicated, consisting of a fairly large drawing engine framework  
(Drawkit) overlaid by an even larger controller/UI and customisation  
layer which is currently twice the size of DrawKit and growing. We're  
talking millions of lines of code spread across some 500+ classes with  
a great deal of inter-object communication at many levels.


I use retain/release throughout, and I still prefer it.

Obviously the potential for retain cycles and other pitfalls is there,  
but you can usually take care of these at a fairly detailed,  
microscopic level. In other words, when a class is developed in  
isolation, if you take care to be mindful of the ownership rules, you  
can avoid these problems easily. Cycles occurring at a higher, macro- 
level, caused by the way the objects interact with each other tends to  
take care of itself. Your design dictates who owns what, and that  
relationship is clear and doesn't vary. Code accordingly. If your  
design is unclear, ill thought-out or non-existent, you'll get into  
trouble. But you will anyway, regardless of the memory management  
technology. In fact GC may even be harmful in helping a bad design  
limp along when really it's the bad design that should be fixed.


Using GC may mean you can avoid even that small degree of necessary  
care, but the ownership rules are straightforward, easily learned and  
committed to mind, and are hardly arcane or arbitrary - they are  
simple and logical. I'd really rather deal with that and the odd bug  
where I forgot something than the performance hit I'm going to take  
when GC kicks in. I know that this hit is small, but so is the effort  
required to use retain/release, so it seems to me we are arguing about  
small stuff here, not big stuff.


I don't really get why the memory management/ownership rules seem to  
be so hard for so many people. But I accept that they are, to some. If  
they are, maybe GC is a godsend to those folk, but for everyone else,  
I just can't see the big deal.


--Graham


___

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: GC pros and cons

[Kyle Sluder]

On Fri, Jun 26, 2009 at 7:37 PM, James Gregurich wrote:
> I actually don;t agree that the system keeping NSFonts around to use them is 
> non-deterministic. The system will get rid of them when it is done with them. 
> that is a perfectly predictable activity. Maybe I don't know what all the 
> machinery is doing or what all the input is that goes into the machinery, but 
> a given set of circumstances will cause the same result each time.

Not true (see my rand() example).

> However, when you have an extra background process controlling the system 
> according to the set of rules you don't control, that is certainly a 
> situation where events will be happening in different sequences no matter 
> that input you feed in. that can cause problems you have to work around. Yes, 
> I'm sure people can come up with an endless list of background processes that 
> drive my app that I don't control. But, adding one more unknown to the list 
> that I can do without quite easily isn't useful.

Do you also avoid threads because of the unpredictability of the scheduler?

> my statement is that I'd rather use shared_ptr & weak_ptr. I'll know exactly 
> what my system is doing in a way that is as predictable as possible yet is 
> completely safe and reliableand maintainable.

Nothing can be more maintainable than code that doesn't exist.

--Kyle Sluder
___

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: GC pros and cons

[James Gregurich]

I actually don;t agree that the system keeping NSFonts around to use them is 
non-deterministic. The system will get rid of them when it is done with them. 
that is a perfectly predictable activity. Maybe I don't know what all the 
machinery is doing or what all the input is that goes into the machinery, but a 
given set of circumstances will cause the same result each time.

However, when you have an extra background process controlling the system 
according to the set of rules you don't control, that is certainly a situation 
where events will be happening in different sequences no matter that input you 
feed in. that can cause problems you have to work around. Yes, I'm sure people 
can come up with an endless list of background processes that drive my app that 
I don't control. But, adding one more unknown to the list that I can do without 
quite easily isn't useful.

my statement is that I'd rather use shared_ptr & weak_ptr. I'll know exactly 
what my system is doing in a way that is as predictable as possible yet is 
completely safe and reliableand maintainable.


 
On Friday, June 26, 2009, at 06:56PM, "Michael Ash"  
wrote:
>On Fri, Jun 26, 2009 at 8:40 PM, James Gregurich wrote:
>>
>> On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder"  
>> wrote:
>>
>>>100% might.  Maybe 0% today, and then tomorrow Apple might release an
>>>update that causes all objects to hang around forever.  You don't
>>>know, and you shouldn't care.
>>
>> I don't. in practice its not particularly relevant as I can't think of an 
>> instance where I made a class' lifecycle dependent on the lifetime of an 
>> NSFont  (just to use your example).
>>
>> I really don't get this whole line of reasoning. I don't get why the fact 
>> that a system keeps an NSFont around justifies me adding a whole new system 
>> to scan memory and look for pointers to determine which ones need to be 
>> released.
>
>I think you've got it backwards. You're the one who said that GC was
>bad because it has nondeterministic behavior for object destruction.
>The rest of us are merely pointing out that Cocoa has nondeterministic
>object destruction in non-GC mode as well.
>
>Mike
>___
>
>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/bayoubengalml%40mac.com
>
>This email sent to bayoubenga...@mac.com
>
>
___

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: GC pros and cons

[James Gregurich]

 
On Friday, June 26, 2009, at 06:39PM, "Kyle Sluder"  
wrote:
>On Fri, Jun 26, 2009 at 6:21 PM, James Gregurich wrote:
>>>That wasn't where I was going with that.  I was making two distinct
>>>points: 1) You can't depend on any Cocoa object actually getting
>>>released at any time.
>>
>> I certainly can the vast majority of the time.
>
>You can also rely on malloc() returning non-NULL a vast majority of
>the time.  It's still sloppy not to check for NULL, even if it's just
>to call abort().

ummm. my system doesn't fail if cocoa keeps an object around longer than I 
expect.



>shared_ptr<> isn't Cocoa, and you still need to participate in Cocoa
>memory management.

I can write cocoa code in C++ quite easily.  I also participlate in cocoa 
memory manage by calling release in my deleter. It all works just fine.


It is indeed true that I am counting on Apple and any 3rd party libs to get 
their retains and releases right. That is something I can live with. If I spot 
a bug in their stuff, I'll just have to deal with it.




>
>>>The occasions where you need objects to "go away in a
>>>well-defined order at a precise time" should not be handled by memory
>>>management.  You should have a separate resource management paradigm
>>>for these sorts of objects, like NSFileHandle (to pick one example)
>>>does.
>>
>> such as shared_ptr and weak_ptr?
>
>These are memory management primitives.  They deal specifically and
>only with the memory consumed by objects.  Their semantics do not
>extend to things like file handles, sockets, or other entities --
>system resources or otherwise -- whose lifetimes you are interested
>in.

hehe. oh yes they do.  You can put any TYPE you want in shared_ptr<>.  If you 
want to put a posix file descriptor in it, just use close() as the custom 
deleter. works great. In fact, I guard SQLite db handles with shared_ptr. 

Here is how you do it:

std::string tmpDbName("test.db");
sqlite3* tmpDbPtr = NULL;
boost::shared_ptr tmpDbSPtr;
int tmpResult = sqlite3_open_v2(tmpDbName.c_str(), &tmpDbPtr, 
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE  | SQLITE_OPEN_NOMUTEX, 
statVSNamePtr);

if(tmpResult != SQLITE_OK)
{
//handle error
return;
}

tmpDbSPtr.reset(tmpDbPtr, sqlite3_close);


this code is completely exception safe and won't leak the db handle under any 
circumstances.







>
>>>Cocoa very intentionally does not conflate the concepts of object
>>>lifetime and resource acquisition.
>>
>> That is an incredibly useful feature of C++.
>
>Welcome to Cocoa, where Resource Acquisition Is Not Initialization.
>Sorry, but there really is no debate on this point.\\


look at the code snippet I just provided and tell me that this use of RAII is 
not useful for guarding ANY resource...cocoa or otherwise.


>
>>>Closures are notoriously hard to implement without some form of
>>>automatic memory management.  Forgetting everything announced and
>>>unannounced about upcoming features of ObjC, we have a small version
>>>of this issue right now, when dealing with NSBeginAlertSheet context
>>>pointers.
>>
>>
>>
>> I just jumped on wikipedia to educate myself on "Closures," but don't see 
>> anything there I couldn't do with shared_ptr and weak_ptr. feel free to 
>> point out a specific thing I couldn't easily accomplish on that page with 
>> shared_ptr and weak_ptr.
>
>The next article you need to read is about the Funarg Problem:
>http://en.wikipedia.org/wiki/Funarg_problem

I'll do that later tonight.



>If weak_ptr<> were able to solve all retain cycle problems, we would
>use in Objective-C (by simply not calling -retain).

heh. THAT will cause a crash if the object has already been released.

but I can call  weak_ptr.lock()  to get shared_ptr instance. If that shared_ptr 
instance is non-null, then the ptr still exists and I have a lock on it that 
prevents it from being released from under me...and weak_ptr/shared_ptr is safe 
to use across threads. 

I'm telling you. this mechanism works great. I'm already using this in a pretty 
big commercial application that is multithreaded.




>Imagine a NIB that contains a window.  On this window lives a text
>field.  The File's Owner of the NIB is an instance of a custom
>NSWindowController subclass (MyWindowController).  MyWindowController
>has a property that the text field binds to.  The window controller
>needs to retain the window, and the window retains the text field (by
>the transitivity of retaining through the view hierarchy), but then
>the text field turns around and retains the window controller again by
>the act of binding to it.  In all of these situations, the objects are
>acting appropriately; none of these relationships can be modeled as a
>weak reference.  But we still have a retain cycle that we need to deal
>with.

ok. I'll work with your scenario

window controller keeps a weak_ptr<> to window.
windows keeps a shared_ptr<> to window controller.
text field keeps a weak_ptr<> to wi

Re: GC pros and cons

[Philip Ershler]

Oh my hell, List Mom, please put a stop to this. The poor horse was  
beaten to death long ago.


Thanks

On Jun 26, 2009, at 7:56 PM, Michael Ash  wrote:

On Fri, Jun 26, 2009 at 8:40 PM, James  
Gregurich wrote:


On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder" > wrote:


100% might.  Maybe 0% today, and then tomorrow Apple might release  
an

update that causes all objects to hang around forever.  You don't
know, and you shouldn't care.


I don't. in practice its not particularly relevant as I can't think  
of an instance where I made a class' lifecycle dependent on the  
lifetime of an NSFont  (just to use your example).


I really don't get this whole line of reasoning. I don't get why  
the fact that a system keeps an NSFont around justifies me adding a  
whole new system to scan memory and look for pointers to determine  
which ones need to be released.


I think you've got it backwards. You're the one who said that GC was
bad because it has nondeterministic behavior for object destruction.
The rest of us are merely pointing out that Cocoa has nondeterministic
object destruction in non-GC mode as well.

Mike
___

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/ershler%40cvrti.utah.edu

This email sent to ersh...@cvrti.utah.edu


___

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: GC pros and cons

[Michael Ash]

On Fri, Jun 26, 2009 at 8:54 PM, Kyle Sluder wrote:
> Closures are notoriously hard to implement without some form of
> automatic memory management.  Forgetting everything announced and
> unannounced about upcoming features of ObjC, we have a small version
> of this issue right now, when dealing with NSBeginAlertSheet context
> pointers.

Well, I think that ignoring Apple's upcoming blocks is a mistake here,
because all the relevant details are now public, their implementation
does not require garbage collection, and it's interesting to see how
they've done it.

Details on how it all works are here:

http://clang.llvm.org/docs/LanguageExtensions.html#blocks

The short version is this: blocks are objects which, in a non-GC app,
just get retained and released as usual. When a block is copied, all
of the object-pointer variables that it references get retained to
keep them alive (and subsequently released when the block is
destroyed).

There are some obvious problems with retain cycles due to this design
which will probably somewhat limit where blocks can be used, but
overall it seems pretty straightforward and effective.

Mike
___

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: GC pros and cons

[Michael Ash]

On Fri, Jun 26, 2009 at 8:40 PM, James Gregurich wrote:
>
> On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder"  
> wrote:
>
>>100% might.  Maybe 0% today, and then tomorrow Apple might release an
>>update that causes all objects to hang around forever.  You don't
>>know, and you shouldn't care.
>
> I don't. in practice its not particularly relevant as I can't think of an 
> instance where I made a class' lifecycle dependent on the lifetime of an 
> NSFont  (just to use your example).
>
> I really don't get this whole line of reasoning. I don't get why the fact 
> that a system keeps an NSFont around justifies me adding a whole new system 
> to scan memory and look for pointers to determine which ones need to be 
> released.

I think you've got it backwards. You're the one who said that GC was
bad because it has nondeterministic behavior for object destruction.
The rest of us are merely pointing out that Cocoa has nondeterministic
object destruction in non-GC mode as well.

Mike
___

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: GC pros and cons

[Kyle Sluder]

On Fri, Jun 26, 2009 at 6:21 PM, James Gregurich wrote:
>>That wasn't where I was going with that.  I was making two distinct
>>points: 1) You can't depend on any Cocoa object actually getting
>>released at any time.
>
> I certainly can the vast majority of the time.

You can also rely on malloc() returning non-NULL a vast majority of
the time.  It's still sloppy not to check for NULL, even if it's just
to call abort().

>> 2) Garbage collection is a useful facility that
>>doesn't solve all problems but makes the most common ones much easier
>>to solve, since you don't have to worry about manual memory
>>management.
>
> okbut I haven't faced such a problem and don't forsee one.

I'll unfortunately have to leave this one alone for the time being...
perhaps we'll revisit this debate in a few months.

> I'm doing exactly that using shared_ptr<>. Maybe there are some cases where 
> cocoa keeps things around beyond my control. but I can get the behavior I 
> want a whole lot of the time by using shared_ptr<>.

shared_ptr<> isn't Cocoa, and you still need to participate in Cocoa
memory management.

>>The occasions where you need objects to "go away in a
>>well-defined order at a precise time" should not be handled by memory
>>management.  You should have a separate resource management paradigm
>>for these sorts of objects, like NSFileHandle (to pick one example)
>>does.
>
> such as shared_ptr and weak_ptr?

These are memory management primitives.  They deal specifically and
only with the memory consumed by objects.  Their semantics do not
extend to things like file handles, sockets, or other entities --
system resources or otherwise -- whose lifetimes you are interested
in.

>>Cocoa very intentionally does not conflate the concepts of object
>>lifetime and resource acquisition.
>
> That is an incredibly useful feature of C++.

Welcome to Cocoa, where Resource Acquisition Is Not Initialization.
Sorry, but there really is no debate on this point.

>>Closures are notoriously hard to implement without some form of
>>automatic memory management.  Forgetting everything announced and
>>unannounced about upcoming features of ObjC, we have a small version
>>of this issue right now, when dealing with NSBeginAlertSheet context
>>pointers.
>
>
>
> I just jumped on wikipedia to educate myself on "Closures," but don't see 
> anything there I couldn't do with shared_ptr and weak_ptr. feel free to point 
> out a specific thing I couldn't easily accomplish on that page with 
> shared_ptr and weak_ptr.

The next article you need to read is about the Funarg Problem:
http://en.wikipedia.org/wiki/Funarg_problem

>>Also, NSWindowController and NSViewController require special voodoo
>>to break retain cycles in NIBs.  This logic is unnecessary in a
>>garbage-collected environment.
>
> that is what weak_ptr<> is for.

If weak_ptr<> were able to solve all retain cycle problems, we would
use in Objective-C (by simply not calling -retain).

Imagine a NIB that contains a window.  On this window lives a text
field.  The File's Owner of the NIB is an instance of a custom
NSWindowController subclass (MyWindowController).  MyWindowController
has a property that the text field binds to.  The window controller
needs to retain the window, and the window retains the text field (by
the transitivity of retaining through the view hierarchy), but then
the text field turns around and retains the window controller again by
the act of binding to it.  In all of these situations, the objects are
acting appropriately; none of these relationships can be modeled as a
weak reference.  But we still have a retain cycle that we need to deal
with.

--Kyle Sluder
___

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: GC pros and cons

[WT]

On Jun 27, 2009, at 3:30 AM, Andy Lee wrote:


On Friday, June 26, 2009, at 09:20PM, "WT"  wrote:

It seems
to me that micro-managing memory can get out-of-hand rather easily on
large projects. By adopting a GC approach, I'd be relinquishing some
control, yes, but I'd be gaining the peace of mind of not having to
debug a potential monster.


Actually the pre-GC way (retain-release) boils down to some simple  
rules that don't seem like micro-management at all to most Cocoa  
developers who have internalized them.  It's true things can get  
hairy, but not as often as you might think.


I was referring specifically to complex retain cycles in a large  
object graph.



you do whatever floats your boat. I'll do what floats mine.


I think my boat sunk, 'cause I was using integers rather than floats.


No, no, it was the memory leaks!


Or a buffer overflow, perhaps ?

___

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: GC pros and cons

[Andy Lee]

On Friday, June 26, 2009, at 09:20PM, "WT"  wrote:
>It seems  
>to me that micro-managing memory can get out-of-hand rather easily on  
>large projects. By adopting a GC approach, I'd be relinquishing some  
>control, yes, but I'd be gaining the peace of mind of not having to  
>debug a potential monster.

Actually the pre-GC way (retain-release) boils down to some simple rules that 
don't seem like micro-management at all to most Cocoa developers who have 
internalized them.  It's true things can get hairy, but not as often as you 
might think.

>> you do whatever floats your boat. I'll do what floats mine.
>
>I think my boat sunk, 'cause I was using integers rather than floats.

No, no, it was the memory leaks!

--Andy


___

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: GC pros and cons

[James Gregurich]

much better response.  thanks.

The sarcastic stuff gets old.

 
On Friday, June 26, 2009, at 05:54PM, "Kyle Sluder"  
wrote:

>That wasn't where I was going with that.  I was making two distinct
>points: 1) You can't depend on any Cocoa object actually getting
>released at any time. 

I certainly can the vast majority of the time. 



> 2) Garbage collection is a useful facility that
>doesn't solve all problems but makes the most common ones much easier
>to solve, since you don't have to worry about manual memory
>management.

okbut I haven't faced such a problem and don't forsee one. 



>
>> If the system decides to keep an NSFont around, that is its business. but if 
>> I need a hierarchy of my own classes to go away in a well-defined order at a 
>> precise time, then I want that control. I don't want a background process 
>> deciding at some arbitrary time where the objects are released.
>
>You don't have that control with -retain/-release as it is.  The
>system might at any point arbitrarily decide to hang on to objects
>that you intend to manage yourself.

>  It seems like you're trying to
>apply an RAII-like pattern to dealing with Cocoa; Cocoa just doesn't
>work this way.  

I'm doing exactly that using shared_ptr<>. Maybe there are some cases where 
cocoa keeps things around beyond my control. but I can get the behavior I want 
a whole lot of the time by using shared_ptr<>.



>The occasions where you need objects to "go away in a
>well-defined order at a precise time" should not be handled by memory
>management.  You should have a separate resource management paradigm
>for these sorts of objects, like NSFileHandle (to pick one example)
>does.

such as shared_ptr and weak_ptr?


>Cocoa very intentionally does not conflate the concepts of object
>lifetime and resource acquisition.

That is an incredibly useful feature of C++. 


>Closures are notoriously hard to implement without some form of
>automatic memory management.  Forgetting everything announced and
>unannounced about upcoming features of ObjC, we have a small version
>of this issue right now, when dealing with NSBeginAlertSheet context
>pointers.



I just jumped on wikipedia to educate myself on "Closures," but don't see 
anything there I couldn't do with shared_ptr and weak_ptr. feel free to point 
out a specific thing I couldn't easily accomplish on that page with shared_ptr 
and weak_ptr.  

The parent function declares a shared_ptr on the stack and passes copy of it to 
the lambda function.  The parent function can return a copy of the shared_ptr 
as well to allow client code to keep the object alive beyond the termination of 
the parent function and the lambda function.


reference:   http://en.wikipedia.org/wiki/Closure_(computer_science)



>
>Also, NSWindowController and NSViewController require special voodoo
>to break retain cycles in NIBs.  This logic is unnecessary in a
>garbage-collected environment.

that is what weak_ptr<> is for.







___

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: GC pros and cons

[WT]

Forgive me for the intrusion, for

a) I am not what one would consider an experienced Cocoa developer,
b) I have not used GC in Cocoa projects yet,
c) my experience with GCs is limited to Java, and
d) I have read most, but not all, the posts in this thread.

Having disclaimed myself, this is what I would like to contribute to  
this thread.


Presumably, the advantages and disadvantages of GC and retain/release  
are only really significant and worth-considering in large and/or  
complex projects. Assuming that to be the case, then what would a  
developer prefer?


1) Yield some control to the GC subsystem and gain on maintainability,  
or


2) Stick to retain/release and have to maintain a potentially  
extremely complicated object graph, with potentially large and  
interlocking retain cycles?


I don't know about other developers, but I'd rather choose 1. It seems  
to me that micro-managing memory can get out-of-hand rather easily on  
large projects. By adopting a GC approach, I'd be relinquishing some  
control, yes, but I'd be gaining the peace of mind of not having to  
debug a potential monster.


And the above doesn't even consider the fact, pointed out by others  
already, that retain/release doesn't guarantee that objects will be  
released when you think they are going to.


On Jun 27, 2009, at 2:49 AM, James Gregurich wrote:


you do whatever floats your boat. I'll do what floats mine.


I think my boat sunk, 'cause I was using integers rather than floats.

(Sorry... I just thought the thread could use a bit of levity just now)

Wagner
___

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: GC pros and cons

[Kyle Sluder]

On Fri, Jun 26, 2009 at 5:40 PM, James Gregurich wrote:
> I really don't get this whole line of reasoning. I don't get why the fact 
> that a system keeps an NSFont around justifies me adding a whole new system 
> to scan memory and look for pointers to determine which ones need to be 
> released.

That wasn't where I was going with that.  I was making two distinct
points: 1) You can't depend on any Cocoa object actually getting
released at any time.  2) Garbage collection is a useful facility that
doesn't solve all problems but makes the most common ones much easier
to solve, since you don't have to worry about manual memory
management.

> If the system decides to keep an NSFont around, that is its business. but if 
> I need a hierarchy of my own classes to go away in a well-defined order at a 
> precise time, then I want that control. I don't want a background process 
> deciding at some arbitrary time where the objects are released.

You don't have that control with -retain/-release as it is.  The
system might at any point arbitrarily decide to hang on to objects
that you intend to manage yourself.  It seems like you're trying to
apply an RAII-like pattern to dealing with Cocoa; Cocoa just doesn't
work this way.  The occasions where you need objects to "go away in a
well-defined order at a precise time" should not be handled by memory
management.  You should have a separate resource management paradigm
for these sorts of objects, like NSFileHandle (to pick one example)
does.

Cocoa very intentionally does not conflate the concepts of object
lifetime and resource acquisition.

>> The creators of garbage collectors don't consider them to be
>>panaceas.  There are a very well known class of problems which GC
>>utterly fails in.  There's also a rather large class of problems which
>>can only be solved (that is, solved by a programmer within a normal
>>human lifespan) with some form of automatic garbage collection.  The
>>Lisp guys can probably come up with boatloads; after all, they've had
>>since the late 50's.
>
>
> really?
>
> I'd find it interesting to see a list of problems that require a garbage 
> collector to manage the memory. Perhaps you could provide that.

Closures are notoriously hard to implement without some form of
automatic memory management.  Forgetting everything announced and
unannounced about upcoming features of ObjC, we have a small version
of this issue right now, when dealing with NSBeginAlertSheet context
pointers.

Also, NSWindowController and NSViewController require special voodoo
to break retain cycles in NIBs.  This logic is unnecessary in a
garbage-collected environment.

None of these are insurmountable, to be sure, but they are a lot
easier with garbage collection.

--Kyle Sluder
___

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: GC pros and cons

[James Gregurich]

sorry. I don't do strawman arguments. a strawman agument would be comparing 
garbage collectors to MMUs and task schedulers. You guys are getting downright 
silly trying to be clever with the sarcasm. I don't feel like playing that 
game. I'll leave that to you twenty-somethings who have the patience to sit 
around arguing over the obvious.


I know exactly what I want and why I want it. you do whatever floats your boat. 
I'll do what floats mine.



On Friday, June 26, 2009, at 05:26PM, "Andy Lee"  wrote:
>On Friday, June 26, 2009, at 07:27PM, "James Gregurich" 
> wrote:
>>I've never seen an objc class that mysteriously hangs around beyond the 
>>destruction of its dependencies (including any autorelease pools that contain 
>>it). I wouldn't be shocked if there were somemaybe some system singletons?
>
>System singletons are not an example of something mysteriously hanging around. 
> If you think they are, you have a very basic misunderstanding.  By design, 
>they do not have all their dependencies destroyed.  No mystery.
>
>>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.
>
>True, but also a complete straw man.
>
>>additionally, I find the notion of adding an extra subsystem that 
>>periodically scans memory looking for pointers to be foolhardy. my code 
>>already knows what needs to be cleaned up and when.
>
>Actually, it very often doesn't.  That's why you never call dealloc, only 
>retain and release.  That's the whole *point* of retain and release.
>
>> I don't need a system sitting in the background scanning memory trying to 
>> clean up behind me.  All I need is a mechanism to do the cleanup in a 
>> maintainable and extensible manner.
>
>You could make very similar arguments about threading or about object 
>orientation -- especially Objective-C's flavor of object orientation.  Why 
>should I let some mysterious scheduler decide on a random order for my code to 
>execute?  Why should I let some mysterious method dispatcher decide which 
>function to call when I know perfectly well what I meant?
>
>>I'm just expressing my personal opinion. I realize GC has its fans who will 
>>disagree.
>
>It's perfectly valid to have a personal level of comfort or discomfort with a 
>given technology (depending not only on conceptual merits but maturity of 
>implementation), but I have no idea where you get the idea this is about 
>fandom.  What, is there a GC team with cheerleaders?  Is there a clique of 
>cool kids who only do retain-release?
>
>--Andy
>
>
>
>
___

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: GC pros and cons

[Kyle Sluder]

On Fri, Jun 26, 2009 at 5:40 PM, David Blanton wrote:
> What?  GC has been around for 25+ years  hardly a modern concept.
> Garbage collection was invented byJohn McCarthy around 1959 to solve the
> problems of manual memory management in Lisp.

Perhaps you missed my direct reference thereto.  ;-)

--Kyle Sluder
___

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: GC pros and cons

[James Gregurich]

 
On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder"  
wrote:

>100% might.  Maybe 0% today, and then tomorrow Apple might release an
>update that causes all objects to hang around forever.  You don't
>know, and you shouldn't care.

I don't. in practice its not particularly relevant as I can't think of an 
instance where I made a class' lifecycle dependent on the lifetime of an NSFont 
 (just to use your example).

I really don't get this whole line of reasoning. I don't get why the fact that 
a system keeps an NSFont around justifies me adding a whole new system to scan 
memory and look for pointers to determine which ones need to be released.  

If the system decides to keep an NSFont around, that is its business. but if I 
need a hierarchy of my own classes to go away in a well-defined order at a 
precise time, then I want that control. I don't want a background process 
deciding at some arbitrary time where the objects are released.

If you like that, then more power to you.




> The creators of garbage collectors don't consider them to be
>panaceas.  There are a very well known class of problems which GC
>utterly fails in.  There's also a rather large class of problems which
>can only be solved (that is, solved by a programmer within a normal
>human lifespan) with some form of automatic garbage collection.  The
>Lisp guys can probably come up with boatloads; after all, they've had
>since the late 50's.


really?

I'd find it interesting to see a list of problems that require a garbage 
collector to manage the memory. Perhaps you could provide that.





___

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: GC pros and cons

[David Blanton]

On Jun 26, 2009, at 5:41 PM, Kyle Sluder wrote:


you're unprepared for the reality of modern
software development



What?  GC has been around for 25+ years  hardly a modern concept.

Garbage collection was invented byJohn McCarthy around 1959 to solve  
the problems of manual memory management in Lisp.


___

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: GC pros and cons

[Andy Lee]

On Friday, June 26, 2009, at 07:27PM, "James Gregurich"  
wrote:
>I've never seen an objc class that mysteriously hangs around beyond the 
>destruction of its dependencies (including any autorelease pools that contain 
>it). I wouldn't be shocked if there were somemaybe some system singletons?

System singletons are not an example of something mysteriously hanging around.  
If you think they are, you have a very basic misunderstanding.  By design, they 
do not have all their dependencies destroyed.  No mystery.

>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.

True, but also a complete straw man.

>additionally, I find the notion of adding an extra subsystem that periodically 
>scans memory looking for pointers to be foolhardy. my code already knows what 
>needs to be cleaned up and when.

Actually, it very often doesn't.  That's why you never call dealloc, only 
retain and release.  That's the whole *point* of retain and release.

> I don't need a system sitting in the background scanning memory trying to 
> clean up behind me.  All I need is a mechanism to do the cleanup in a 
> maintainable and extensible manner.

You could make very similar arguments about threading or about object 
orientation -- especially Objective-C's flavor of object orientation.  Why 
should I let some mysterious scheduler decide on a random order for my code to 
execute?  Why should I let some mysterious method dispatcher decide which 
function to call when I know perfectly well what I meant?

>I'm just expressing my personal opinion. I realize GC has its fans who will 
>disagree.

It's perfectly valid to have a personal level of comfort or discomfort with a 
given technology (depending not only on conceptual merits but maturity of 
implementation), but I have no idea where you get the idea this is about 
fandom.  What, is there a GC team with cheerleaders?  Is there a clique of cool 
kids who only do retain-release?

--Andy


___

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: GC pros and cons

[Kyle Sluder]

On Fri, Jun 26, 2009 at 4:27 PM, James Gregurich wrote:
> ok. What percentage of cocoa classes will exhibit the behavior you describe? 
> I've never seen an objc class that mysteriously hangs around beyond the 
> destruction of its dependencies (including any autorelease pools that contain 
> it). I wouldn't be shocked if there were somemaybe some system singletons?

100% might.  Maybe 0% today, and then tomorrow Apple might release an
update that causes all objects to hang around forever.  You don't
know, and you shouldn't care.

> If 90% of objc classes are completely deterministic in their life cycle 
> behavior with retain/release and 10% aren't, I'll not use the 10% to make the 
> case that I should introduce even more entropy into my system by using 
> garbage collection.

If this is your attitude you're unprepared for the reality of modern
software development.  And I suggest you never touch NSFont, NSColor,
NSWindow, or NSMenu; they might stick around longer than you intended!

> 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.

Then Cocoa's obviously not your cup of tea.

> additionally, I find the notion of adding an extra subsystem that 
> periodically scans memory looking for pointers to be foolhardy. my code 
> already knows what needs to be cleaned up and when. I don't need a system 
> sitting in the background scanning memory trying to clean up behind me.  All 
> I need is a mechanism to do the cleanup in a maintainable and extensible 
> manner.

"My code already knows how it's going to use its memory; why should we
have some stupid little chip -- watchyacallit, an MMU? -- to do that
for me?"  The creators of garbage collectors don't consider them to be
panaceas.  There are a very well known class of problems which GC
utterly fails in.  There's also a rather large class of problems which
can only be solved (that is, solved by a programmer within a normal
human lifespan) with some form of automatic garbage collection.  The
Lisp guys can probably come up with boatloads; after all, they've had
since the late 50's.

--Kyle Sluder
___

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: GC pros and cons

[James Gregurich]

the previous response to Bill is relevant to this response.


ok. What percentage of cocoa classes will exhibit the behavior you describe? 
I've never seen an objc class that mysteriously hangs around beyond the 
destruction of its dependencies (including any autorelease pools that contain 
it). I wouldn't be shocked if there were somemaybe some system singletons? 

If 90% of objc classes are completely deterministic in their life cycle 
behavior with retain/release and 10% aren't, I'll not use the 10% to make the 
case that I should introduce even more entropy into my system by using garbage 
collection.

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. 


additionally, I find the notion of adding an extra subsystem that periodically 
scans memory looking for pointers to be foolhardy. my code already knows what 
needs to be cleaned up and when. I don't need a system sitting in the 
background scanning memory trying to clean up behind me.  All I need is a 
mechanism to do the cleanup in a maintainable and extensible manner.

I'm just expressing my personal opinion. I realize GC has its fans who will 
disagree. Personally, think GC should have been left in the realm of scripting 
languages where it belongs. HOWEVER, I will admit that I don't know if the 
cocoa runtime could be retrofitted to use smart pointers without breaking 
compatibility. So, maybe there was no other choice in fixing the perils of 
manual memory management in objcI'd buy that statement if it was made.







On Friday, June 26, 2009, at 02:52PM, "Michael Ash"  
wrote:
>On Fri, Jun 26, 2009 at 2:31 PM, James Gregurich wrote:
>>
>> If my resource is handed off to some external subsystem for release and I 
>> can't DETERMINE the order of the releases with respect to each other and 
>> other components of my code, then I would call that non-deterministic and 
>> undesirable.
>
>If nondeterministic memory deallocation is a dealbreaker for you, then
>Cocoa is not for you, pure and simple.
>
>You cannot predict when your objects will be destroyed in Cocoa.
>Garbage collection is irrelevant to this fact, and changes nothing
>about it except the degree.
>
>Even a simple alloc/init/release pair is not guaranteed to destroy the
>object on the release. The init method could store a strong reference
>away somewhere, or do a retain/autorelease combo, or pass a reference
>off to another thread, and now you're screwed.
>
>All GC does is make it happen more often. You *never* could rely on
>object lifetimes. If your non-GC code relies on precisely controlling
>object lifetimes, then you have a bug, and should fix it.
>
>Mike
>___
>
>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/bayoubengalml%40mac.com
>
>This email sent to bayoubenga...@mac.com
>
>
___

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: GC pros and cons

[Michael Ash]

On Fri, Jun 26, 2009 at 2:31 PM, James Gregurich wrote:
>
> If my resource is handed off to some external subsystem for release and I 
> can't DETERMINE the order of the releases with respect to each other and 
> other components of my code, then I would call that non-deterministic and 
> undesirable.

If nondeterministic memory deallocation is a dealbreaker for you, then
Cocoa is not for you, pure and simple.

You cannot predict when your objects will be destroyed in Cocoa.
Garbage collection is irrelevant to this fact, and changes nothing
about it except the degree.

Even a simple alloc/init/release pair is not guaranteed to destroy the
object on the release. The init method could store a strong reference
away somewhere, or do a retain/autorelease combo, or pass a reference
off to another thread, and now you're screwed.

All GC does is make it happen more often. You *never* could rely on
object lifetimes. If your non-GC code relies on precisely controlling
object lifetimes, then you have a bug, and should fix it.

Mike
___

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: GC pros and cons

[James Gregurich]

sure. if I'm sharing ownership of an object with the OS or some library, then 
I'm granting that code the option to keep the object around a long as it needs 
it. You're right. I can't predict exactly when the object might go away. If 
something isn't going away, it is because some system is actually keeping it 
around for a reason. I can code around that reality to keep my code running in 
an orderly and predictable fashion.

That isn't the same thing as my system being dependent on when a background 
process kicks in and starts scanning memory looking for pointers in use.

Aside from that, for objects that are entirely owned by my code, I can 
precisely control their lifetimes by the retain count. There is zero 
non-determinism there. 

shared_ptr does retain counting in a way that is easy to maintain and extend 
without the perils of manually releasing and retaining pointers.  That gives me 
the reliability and safety I need without introducing a whole new 
unknown-element to my code base that will cause its own issues that I'll have 
to code around.


another benefitshared_ptr is cross platform.  so, on the mac, I store objc 
objects in them. On windows, the same datamembers can take windows-specific 
structures and manage them.   shared_ptr works great to put in a header 
intended to be on multiple platforms. in the implementation file, I can stick 
whatever I want in that shared_ptr and give it a custom deleter. this makes it 
really straightforward to use common header files with OS-specific 
implementations.

yea...yea...yea...you Apple employees don't have to worry about Windows, but 
I'm not that fortunate.  :)




On Friday, June 26, 2009, at 12:08PM, "Bill Bumgarner"  wrote:
>On Jun 26, 2009, at 1:31 PM, James Gregurich wrote:
>> If my resource is handed off to some external subsystem for release  
>> and I can't DETERMINE the order of the releases with respect to each  
>> other and other components of my code, then I would call that non- 
>> deterministic and undesirable.
>
>As soon as your resource is handed off to any subsystem that you did  
>not write, you can't determine the order of releases.   Said subsystem  
>might release or it might cache for a while or it might retain it for  
>purposes of background processing (to be released later) or it might  
>autorelease or it might retain then autorelease in a different thread.
>
>The point is the same as -retainCount.  Once your object goes through  
>any of the system APIs, there is a chance that the retain count will  
>change and said behavior may differ based on architecture, OS release,  
>or something else.
>
>b.bum
>
>
>
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 26, 2009, at 1:31 PM, James Gregurich wrote:
If my resource is handed off to some external subsystem for release  
and I can't DETERMINE the order of the releases with respect to each  
other and other components of my code, then I would call that non- 
deterministic and undesirable.


As soon as your resource is handed off to any subsystem that you did  
not write, you can't determine the order of releases.   Said subsystem  
might release or it might cache for a while or it might retain it for  
purposes of background processing (to be released later) or it might  
autorelease or it might retain then autorelease in a different thread.


The point is the same as -retainCount.  Once your object goes through  
any of the system APIs, there is a chance that the retain count will  
change and said behavior may differ based on architecture, OS release,  
or something else.


b.bum

___

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: GC pros and cons

[James Gregurich]

If my resource is handed off to some external subsystem for release and I can't 
DETERMINE the order of the releases with respect to each other and other 
components of my code, then I would call that non-deterministic and undesirable.

feel free to disagree. the purpose of my message was to publish a solution I 
found useful. One is free to use it or ignore it.


On Thursday, June 25, 2009, at 11:39PM, "Chris Idou"  wrote:
>
>
>
>
>From: James Gregurich 
>
>> I have read up on GC, and I don't like the idea of introducing 
>> non-deterministic behavior into my code base. 
>
>
>I would question the assertion that GC introduces non-deterministic behavior, 
>unless you consider the time it takes for particular code to execute to be 
>"behavior".
>
>In which case standard malloc/free is not deterministic either, since 
>algorithms for amalgamating free areas in the heap are not exactly 
>predictable, and the time they take will not be constant across different 
>calls.
>
>That's why if you were controlling the space shuttle you wouldn't use 
>malloc/free OR GC.
>
>
>  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
>Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[Eric Hermanson]

Everyone knows there's no garbage collection on the iPhone because the  
Waste Management Union #601 local convinced the nationwide union to  
protest their low wages by striking.  They apparently didn't want to  
add one more garbage route to their workload with no increase in pay.   
I doubt we'll see garbage collection on the iPhone now because of  
them.  F-ing unions.





On Jun 25, 2009, at 9:33 PM, Bill Bumgarner wrote:


On Jun 25, 2009, at 7:58 PM, Chris Idou wrote:
Bill I don't know if this was discussed before, but could you  
discuss the lack of GC on the iPhone?


Not enough hours in the day to get everything done

(No, I can't speculate about things that don't exist).

b.bum

___

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/zmonster%40mac.com

This email sent to zmons...@mac.com


___

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: GC pros and cons

[Chris Idou]

From: James Gregurich 

> I have read up on GC, and I don't like the idea of introducing 
> non-deterministic behavior into my code base. 


I would question the assertion that GC introduces non-deterministic behavior, 
unless you consider the time it takes for particular code to execute to be 
"behavior".

In which case standard malloc/free is not deterministic either, since 
algorithms for amalgamating free areas in the heap are not exactly predictable, 
and the time they take will not be constant across different calls.

That's why if you were controlling the space shuttle you wouldn't use 
malloc/free OR GC.


  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[James Gregurich]

consistently using the technique pushes the null check to one or two  
placessuch as when the pointer is alloc'ed.


regardless of whether messaging nil is a problem or not, if nil isn't  
a a valid state for a variable, I check it and throw an exception as a  
matter of defensive programming. in particular, if a data member is a  
pointer that is available via accessor, I put the null check in the  
accessor with the accessor returning a reference (rather than a  
pointer) to the type. Client code calling the accessor need not worry  
about the value being in an invalid state. If the value is in an  
invalid state, an exception is thrown and everything cleanly unwinds  
and the system can react and cleanly recover.





On Jun 25, 2009, at 10:13 PM, Stephen J. Butler wrote:

On Fri, Jun 26, 2009 at 12:06 AM, James Gregurich> wrote:
I also take advantage of references in C++ to pass objc objects  
around
without having to do null checks all over the place to keep code  
resilent.


-(void) passMyObject: (NSObject&) theObj
{
  NSLog(@"%@", &theObj);
}

since the function takes a reference, client code knows never to  
pass a null

to the function.


Huh? When you call the function, don't you have to eventually do
[something passMyObject:*anObject]? To me, that doesn't eliminate the
nil check, just move it somewhere else.

Also, messaging nil objects isn't a problem. It's only an issue with
the collections.
___

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/bayoubengalml%40mac.com

This email sent to bayoubenga...@mac.com


___

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: GC pros and cons

[Stephen J. Butler]

On Fri, Jun 26, 2009 at 12:06 AM, James Gregurich wrote:
> I also take advantage of references in C++ to pass objc objects around
> without having to do null checks all over the place to keep code resilent.
>
> -(void) passMyObject: (NSObject&) theObj
> {
>NSLog(@"%@", &theObj);
> }
>
> since the function takes a reference, client code knows never to pass a null
> to the function.

Huh? When you call the function, don't you have to eventually do
[something passMyObject:*anObject]? To me, that doesn't eliminate the
nil check, just move it somewhere else.

Also, messaging nil objects isn't a problem. It's only an issue with
the collections.
___

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: GC pros and cons

[James Gregurich]

I'll speak up and throw a wrinkle into this discussion. I found it  
useful and may some others will also.


I have read up on GC, and I don't like the idea of introducing non- 
deterministic behavior into my code base. However, it is true that  
manually retaining and releasing pointers is inherently error-prone.


Personally, my solution is objc++ with the boost::shared_ptr  
template.  The following code works great...its easy to maintain and  
understand...it makes it easy to share objects across threads  
safelyit automatically manages the memory with a retain count in a  
manner completely compatible with NSAutoreleasePool.




void releaseNSObject(NSObject* theObjPtr)
{
[theObjPtr release];
}




boost::shared_ptr tmpStringSPtr([[NSString alloc] init],  
releaseNSObject);



Yes, it uses an extra int per object keeping an extra retain count,  
but I'll trade that for the reliability and maintainability I get in  
return. For the work I do, what is being pointed to is almost always  
far larger than 4 (or 8) bytes.




I also take advantage of references in C++ to pass objc objects around  
without having to do null checks all over the place to keep code  
resilent.



-(void) passMyObject: (NSObject&) theObj
{
NSLog(@"%@", &theObj);
}

since the function takes a reference, client code knows never to pass  
a null to the function.






On Jun 25, 2009, at 2:00 PM, Peter Ammon wrote:



On Jun 25, 2009, at 1:42 PM, Bill Bumgarner wrote:


On Jun 25, 2009, at 3:14 PM, Peter Ammon wrote:
In any case, it's been my experience that GC makes memory  
management much easier, but precious resource management somewhat  
harder.  It's harder because GC forces more of a divorce between  
the management of memory and precious resources, and the precious  
resource management techniques are about on the level with C circa  
1989.


Really, retain/release requires such a separation, too.  At least,  
it does for relatively complex, often concurrent, piles of code.




I totally agree, which is why I said "more of" a divorce.  Since  
retain/release is more deterministic than GC, it allows you to  
tolerate ordering dependencies  and tying resource lifetime to  
memory lifetime for longer.  But it ultimately breaks down as  
complexity increases, just as you say.


The switch to GC has forced me to redesign a number of classes.  But  
I usually find that the redesigned classes work better under retain/ 
release as well.


-Peter

___

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/bayoubengalml%40mac.com

This email sent to bayoubenga...@mac.com


___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 10:32 PM, Adam R. Maxwell wrote:
Interesting.  I found the Xcode editor to be unusably slow on a  
PowerBook G4 when Leopard was released; in fact, contrary to Bill's  
statement, I found that it grew worse in the last few months of  
Leopard seeding.  I'm still sore about having to buy a MacBook Pro  
just to avoid beachballs while typing (rdar://problem/5572897).   
Even said MacBook Pro needs 4 GB of RAM to avoid hanging when  
switching to Xcode, since the collector thread evidently causes  
paging in to scan memory (which caused a beachball and hiccups  
switching apps in Spaces).



The specific issue of Xcode typing performance has been optimized  
significantly with each successive release.  The underlying problem  
for #5572897 was that the parser used to color the code and do a bunch  
of other stuff was both inefficient and tickled the collector in just  
the wrong way.


Bringing this back to cocoa-dev specific issues.

Yes, the collector will keep more memory "hot" in an application than  
using retain/release.   Where this comes into play is when you (a)  
hide an application and (b) do enough stuff in other applications that  
it causes the hidden app's pages to be paged out.


When reactivated, the app will have to pagein anything it needs to  
touch.   GC can cause more stuff to be paged in.


However, in a complex application (like Xcode) that manages lots of  
stuff for which "is it up to date" checks must be performed semi- 
regularly, there will be a lot of page-thrash on reactivation  
regardless of GC or Non-.


Example;   try using Aperture for a while and really build up a good  
sized working set.  Hide it and beat on Xcode.  Then activate  
Aperture.   It can take a long time before the app is responsive again.


The bottom line is that you want to reduce the footprint of your  
application as much as you can as early as you can.   Ditch objects.   
Prune caches.  Optimize your undo stack to have a semi-minimal  
representation of the items within the stack.   It'll lead to better  
overall system performance and make your app feel more snappy as your  
user activates/deactivates it.


b.bum
___

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: GC pros and cons

[Chris Idou]

I guess the necessity to scan and page in memory is a legitimate downside for 
VM systems. It's possible I've seen xcode pause when switching apps, but never 
thought about it being related to GC scans, but just paging in the app. I'd 
probably forgotten that XCode is GC.

...of course, the iPhone does not have virtual memory, so its not an issue 
there.





From: Adam R. Maxwell 
To: cocoa-dev Dev 
Sent: Friday, 26 June, 2009 1:32:51 PM
Subject: Re: GC pros and cons


On Jun 25, 2009, at 8:19 PM, Chris Idou wrote:

> I still use XCode in one location where I work on a core-solo Mini. 
> Performance is good. No problems at all, no pauses.

Interesting.  I found the Xcode editor to be unusably slow on a PowerBook G4 
when Leopard was released; in fact, contrary to Bill's statement, I found that 
it grew worse in the last few months of Leopard seeding.  I'm still sore about 
having to buy a MacBook Pro just to avoid beachballs while typing 
(rdar://problem/5572897).  Even said MacBook Pro needs 4 GB of RAM to avoid 
hanging when switching to Xcode, since the collector thread evidently causes 
paging in to scan memory (which caused a beachball and hiccups switching apps 
in Spaces).


  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[Adam R. Maxwell]

On Jun 25, 2009, at 8:19 PM, Chris Idou wrote:

I still use XCode in one location where I work on a core-solo Mini.  
Performance is good. No problems at all, no pauses.


Interesting.  I found the Xcode editor to be unusably slow on a  
PowerBook G4 when Leopard was released; in fact, contrary to Bill's  
statement, I found that it grew worse in the last few months of  
Leopard seeding.  I'm still sore about having to buy a MacBook Pro  
just to avoid beachballs while typing (rdar://problem/5572897).  Even  
said MacBook Pro needs 4 GB of RAM to avoid hanging when switching to  
Xcode, since the collector thread evidently causes paging in to scan  
memory (which caused a beachball and hiccups switching apps in Spaces).





smime.p7s
Description: S/MIME cryptographic signature
___

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: GC pros and cons

[Michael Ash]

On Thu, Jun 25, 2009 at 4:14 PM, Peter Ammon wrote:
> 2) Require that malloc be robust against multiple free()s on the same
> pointer
>
> The second solution is a lot easier to implement.

Can you elaborate on this? Thinking about how to accomplish this, it
seems like an extremely difficult problem. The only thing I've been
able to come up with that would work would be to make all pointers be
implemented as an address plus a counter. Then when you call free, it
checks your pointer's counter against the latest one allocated there,
and if your counter is stale, it does nothing. This would be a massive
change to the language that would break binary compatibility with
everything and bloat pointer sizes hugely, since it would really
require at least 64 bits for the counter to be properly robust.

Is there some easy solution to this that I'm overlooking? Silently
returning if you pass a freed block is not sufficient, because that
block could have been reused by the time the second free() happens,
causing a chunk of memory owned by someone else to be spontaneously
destroyed.

Mike
___

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: GC pros and cons

[Chris Idou]

I still use XCode in one location where I work on a core-solo Mini. Performance 
is good. No problems at all, no pauses.





From: Rob Keniger 
To: cocoa-dev Dev 
Sent: Friday, 26 June, 2009 12:20:48 PM
Subject: Re: GC pros and cons


On 26/06/2009, at 10:58 AM, Chris Idou wrote:

> Bill I don't know if this was discussed before, but could you discuss the 
> lack of GC on the iPhone?


I suspect it is for performance reasons. The Objective-C garbage collector is 
designed to run in a separate thread on the Mac, which means it can run on its 
own CPU core separate to the main thread.

In single-core systems, even on the Mac, performance of Garbage Collected code 
is very poor because the collector has to share CPU time with the main thread. 
When Xcode 3 (a GC app) was first released in the Leopard betas there were 
still quite a few people with single-CPU PowerPC laptops who found that Xcode 
could barely keep up with their typing. On dual-core machines it was fine.

The iPhone has a single-core CPU and a slow one at that, so while I am sure 
that GC could be turned on, it would probably make developers very unhappy.

--
Rob Keniger



___

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/idou747%40yahoo.com

This email sent to idou...@yahoo.com



  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 9:20 PM, Rob Keniger wrote:
In single-core systems, even on the Mac, performance of Garbage  
Collected code is very poor because the collector has to share CPU  
time with the main thread. When Xcode 3 (a GC app) was first  
released in the Leopard betas there were still quite a few people  
with single-CPU PowerPC laptops who found that Xcode could barely  
keep up with their typing. On dual-core machines it was fine.


I won't comment on anything iPhone related regarding GC and I would  
ask that we keep the speculation off of the cocoa-dev list as it is  
off-topic and unproductive.


To the above;   When Xcode was first released in the Leopard betas,  
Garbage Collection actually *didn't* run in a separate thread.  That  
wasn't ready yet and it was far more critical to get Xcode up and  
running with GC on so as to shake out the entire system than it was to  
optimize GC.


Thus, you are correct that the initial seeds of Xcode were pretty  
darned slow, but they were pretty darned slow on multi-core systems,  
too!   The were doubleplus slow on single core systems, though, more  
because of Xcodes use of thread and the lack of appropriate throttling  
than because of GC.


By the time Leopard shipped, the collector had become significantly  
more efficient and had been moved off to a separate thread.   As well,  
Xcode had also been tuned, along with a bunch of system frameworks,  
and the overall performance was vastly improved.


Obviously, discussing details of Snow Leopard on cocoa-dev isn't yet  
possible.  If you want to know more about Snow Leopard specific  
optimizations and have access, ask away in http://devforums.apple.com/.


b.bum

___

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: GC pros and cons

[Rob Keniger]

On 26/06/2009, at 10:58 AM, Chris Idou wrote:

Bill I don't know if this was discussed before, but could you  
discuss the lack of GC on the iPhone?



I suspect it is for performance reasons. The Objective-C garbage  
collector is designed to run in a separate thread on the Mac, which  
means it can run on its own CPU core separate to the main thread.


In single-core systems, even on the Mac, performance of Garbage  
Collected code is very poor because the collector has to share CPU  
time with the main thread. When Xcode 3 (a GC app) was first released  
in the Leopard betas there were still quite a few people with single- 
CPU PowerPC laptops who found that Xcode could barely keep up with  
their typing. On dual-core machines it was fine.


The iPhone has a single-core CPU and a slow one at that, so while I am  
sure that GC could be turned on, it would probably make developers  
very unhappy.


--
Rob Keniger



___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 7:58 PM, Chris Idou wrote:
Bill I don't know if this was discussed before, but could you  
discuss the lack of GC on the iPhone?


Not enough hours in the day to get everything done

(No, I can't speculate about things that don't exist).

b.bum

___

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: GC pros and cons

[Chris Idou]

From: Bill Bumgarner 
..


Bill I don't know if this was discussed before, but could you discuss the 
lack of GC on the iPhone?



  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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: GC pros and cons

[Peter Ammon]

On Jun 25, 2009, at 1:42 PM, Bill Bumgarner wrote:


On Jun 25, 2009, at 3:14 PM, Peter Ammon wrote:
In any case, it's been my experience that GC makes memory  
management much easier, but precious resource management somewhat  
harder.  It's harder because GC forces more of a divorce between  
the management of memory and precious resources, and the precious  
resource management techniques are about on the level with C circa  
1989.


Really, retain/release requires such a separation, too.  At least,  
it does for relatively complex, often concurrent, piles of code.




I totally agree, which is why I said "more of" a divorce.  Since  
retain/release is more deterministic than GC, it allows you to  
tolerate ordering dependencies  and tying resource lifetime to memory  
lifetime for longer.  But it ultimately breaks down as complexity  
increases, just as you say.


The switch to GC has forced me to redesign a number of classes.  But I  
usually find that the redesigned classes work better under retain/ 
release as well.


-Peter

___

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: GC pros and cons

[Peter Ammon]

On Jun 25, 2009, at 1:16 PM, Peter Duniho wrote:


On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:


[...] .NET users often call Dispose()
explicitly, because it is useful in situations other than inside  
using

blocks.


Though, to be clear (lest the tendency to want to put down the other  
be allowed to go too far)...


The requirement in .NET that Dispose() be safe to call multiple  
times has very little to do with how _client_ code is expected to  
use it, and more to do with the GC system.  In particular, the order  
of finalizer execution is indeterminate, and the usual job of a  
finalizer is to call Dispose() on the object in which it's  
implemented, which in turn may call Dispose() on other objects  
referenced by that object.


Without a requirement that Dispose() be safe to call multiple times,  
the caller of Dispose() would have to always check to see whether  
the object has been disposed yet, because an object that is being  
disposed by some other object being finalized might already have  
been disposed by the first object's finalizer.


Certainly it would be unusual, and generally a sign of sloppy  
programming, for _client_ code to call Dispose() on an object more  
than once (or for the finalizer to be executed, for that matter).   
The rules are there to make the system more robust, not to encourage  
sloppy programming (though of course, unfortunately, the former does  
sometimes lead to the latter).


Thanks for that explanation!  That makes sense.  I'm happy that the  
idempotence of Dispose() has a sane justification.

___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 3:14 PM, Peter Ammon wrote:
In any case, it's been my experience that GC makes memory management  
much easier, but precious resource management somewhat harder.  It's  
harder because GC forces more of a divorce between the management of  
memory and precious resources, and the precious resource management  
techniques are about on the level with C circa 1989.


Really, retain/release requires such a separation, too.  At least, it  
does for relatively complex, often concurrent, piles of code.


I'll speak anecdotally instead of making broad claims.  I have had to  
track down and fix more than a dozen bugs over the years that have all  
boiled down to exhaustion of some scarce resource such as a file  
descriptor, server connection or the like.


While the cause was sometimes simply a leak, it has often been caused  
by unexpectedly long delays until the autorelease pool was drained.


Even with leaks, a small leak is something that should be fixed, but  
is also something that you can live with for a while -- leaking 300  
allocation nodes of 48 bytes each, say, every time a document is  
closed is only 14k per document and, thus, the user is gonna have to  
open/close an awful lot of documents to cause a problem.


However, if even a subset of those 300 nodes also contains some scarce  
resource, what is a minor problem will then be a major, possibly  
catastrophic, problem.


As well, if there are any kind of ordering dependencies when tearing  
down stuff, your code's fragility will be greatly reduced by moving  
the dependencies outside of memory reclamation.  Otherwise, one stray - 
autorelease will cause the house of cards to crumble.


b.bum
___

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: GC pros and cons

[Peter Duniho]

On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:


[...] .NET users often call Dispose()
explicitly, because it is useful in situations other than inside using
blocks.


Though, to be clear (lest the tendency to want to put down the other  
be allowed to go too far)...


The requirement in .NET that Dispose() be safe to call multiple times  
has very little to do with how _client_ code is expected to use it,  
and more to do with the GC system.  In particular, the order of  
finalizer execution is indeterminate, and the usual job of a finalizer  
is to call Dispose() on the object in which it's implemented, which in  
turn may call Dispose() on other objects referenced by that object.


Without a requirement that Dispose() be safe to call multiple times,  
the caller of Dispose() would have to always check to see whether the  
object has been disposed yet, because an object that is being disposed  
by some other object being finalized might already have been disposed  
by the first object's finalizer.


Certainly it would be unusual, and generally a sign of sloppy  
programming, for _client_ code to call Dispose() on an object more  
than once (or for the finalizer to be executed, for that matter).  The  
rules are there to make the system more robust, not to encourage  
sloppy programming (though of course, unfortunately, the former does  
sometimes lead to the latter).


I admit, I'm not well-versed on what the equivalent paradigm in Obj-C/ 
Cocoa is.  But, surely it's useful even in Obj-C/Cocoa to provide  
protections within the language and framework against sloppy  
programming, even as it should be clear that sloppy programming isn't  
to be tolerated.


Pete
___

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: GC pros and cons

[Peter Ammon]

On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:


On Thu, Jun 25, 2009 at 11:39 AM, Peter Ammon wrote:
Are you saying that it's not sloppy to close a file twice, unlock a  
lock

twice, etc.?


It sounds to me like you were originally referring to language
implementation sloppiness, which has nothing to do with closing a file
twice, unlocking locks multiple times, etc. (client sloppiness).


Well, I can make my point with an analogy.

Anyone who has written C or C++ has committed a double free() at some  
point.  This usually indicates that parts of the program aren't  
coordinating properly.  We can apply ad-hoc fixes, but this is a  
common-enough error that it's worth coming up with a general  
solution.  Two possible solutions are:


1) Improve coordination techniques, such by adding garbage collection,  
reference counting, etc.
2) Require that malloc be robust against multiple free()s on the same  
pointer


The second solution is a lot easier to implement.  But it's really  
just papering over the problem, because double free()s are found with  
other bugs, such as deference-after-free or race conditions.


So when I see that Dispose() is required to be robust against multiple  
calls on the same object, it makes me think they encountered the same  
problem as double free(), but chose the second solution.  Client  
sloppiness thus informed the framework design.


In any case, it's been my experience that GC makes memory management  
much easier, but precious resource management somewhat harder.  It's  
harder because GC forces more of a divorce between the management of  
memory and precious resources, and the precious resource management  
techniques are about on the level with C circa 1989.


I mean, C# has the using statement, which works well as long as your  
precious resource's lifetime is tied to some scope.  And we have the  
explicit Dispose() call, which works well as long as you have some  
external way to coordinate between multiple clients of the object.   
There's an obvious analogy to stack allocation and free(), respectively.


-Peter

___

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: GC pros and cons

[Kyle Sluder]

On Thu, Jun 25, 2009 at 11:39 AM, Peter Ammon wrote:
> Are you saying that it's not sloppy to close a file twice, unlock a lock
> twice, etc.?

It sounds to me like you were originally referring to language
implementation sloppiness, which has nothing to do with closing a file
twice, unlocking locks multiple times, etc. (client sloppiness).

> Python doesn't require that its contexts be robust against multiple calls to
> __exit__ (its answer to Dispose()).

Now we're back to implementation sloppiness.  I see no guarantee that
__exit__ will only be called once.  Python users don't typically call
__enter__ and __exit__ explicitly; .NET users often call Dispose()
explicitly, because it is useful in situations other than inside using
blocks.

--Kyle Sluder
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 11:41 AM, Peter Duniho wrote:
Well, as far as I'm concerned that's a bug then, and a somewhat  
silly one at that.  There should be no reason they couldn't easily  
address that scenario, simply by using the thread attempting to do  
the allocation to run the collection code (with the usual  
synchronization/execution management that you'd need in any  
collection/compaction scenario).


Heh-- yes, problems always seems silly and trivial when you haven't  
studied them thoroughly.  :)


I made the assumption that this should be an easy bug to address and,  
not much research later, realized it is both very tough and not really  
that important.


The first problem is that by the time allocation failures start  
happening, the app and/or system is already so far into the weeds that  
recovery isn't really going to be possible.   For almost all  
applications, an allocation failure is only caused by other bugs in  
the app and no amount of exhaustive collection is going help.


Secondly, this problem goes away in the move to 64 bit.  More or less,  
anyway, as the collector has a limit to the total size of the GC zone.  
Given the emphasis on 64 bit in Snow Leopard and that all Macs run 64  
bit applications and have done so for quite a long time (the Mac Mini  
being the last to be updated), there were better uses of the limited  
engineering resource available.


As well, any solution that responds to rampant memory consumption by  
spinning up the CPU(s) is held as suspect by default.  It doesn't  
benefit the user experience to have an application start sucking down  
even more system resources in response to having already sucked down  
too many system resources to start with!


The one allocation failure that is terribly relevant is when  
allocation/free events outrun the collector.  That is, when there is  
so much temporary stuff being created and destroyed that the collector  
can't keep up.   This is a known issue in Leopard and has been largely  
addressed in Snow Leopard, but it is still possible to trigger said  
failure mode.


However, it is equally as often the case that such a failure mode is  
better addressed by refactoring the application to recycle objects  
instead of dealloc/alloc'ing them.


But then, that just reinforces the point that the Obj-C/Cocoa  
garbage collection implementation has some refinement left to  
accomplish.  I'm glad to hear there've been bugs submitted on the  
issue; I expect Apple will address them eventually.  Until they do,  
people who say that GC-managed memory in Cocoa isn't quite fully  
baked yet will actually have a good point.  ;)


Not really.

As noted above, allocation failures are generally a symptom and not a  
problem in and of themselves.  An application failing due to  
allocation failures is most likely suffering from one or more of a  
handful of things, none of which are specific to GC:


- leaks (Yes, you can write leaky GC code)
- poor design
- a user patient enough to throw a quantity of data at the app that  
the developer never thought possible


b.bum

___

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: GC pros and cons

[Marcel Weiher]

On Jun 25, 2009, at 0:54 , Peter Duniho wrote:


Furthermore, it is more typical that there _is_ space already  
available on the heap to satisfy an allocation request, and in a  
typical GC system allocations are much faster than for the alloc/ 
free paradigm.  I admit, I don't know the specifics of the Obj-C  
system, but in other systems an allocation is simply a matter of  
updating a _single_ pointer and of course there are no explicit  
deallocations at all.


This is true for those other systems.  It is not true for Apple's GC.   
It does not use bump-pointer allocation, and because it is not a  
copying collector, it actually does have to explicitly deallocate  
memory.  Maybe this will change in the future, but I wouldn't exactly  
hold my breath, because introducing a copying collector into a  
language with unrestricted pointers (and pointer arithmetic!) is not  
exactly trivial.




Its not reasonable to say "but virtual memory will solve that  
problem" because it just won't.


Nobody's said that.  A GC system really has practically the same  
relationship with the virtual memory manager as the retain/release  
system.


That's not entirely true:  scanning GC systems have a tendency to, as  
the name implies, scan all memory that's in use, potentially causing  
paging that an RC system will not have.  Of course, they also try to  
optimize this, and copying collectors can often do a good job of  
keeping young-space in the caches.  Alas, we don't have a copying  
collector.


As has been pointed out, this isn't a .NET list, and I don't care  
strongly about this topic, except in as much as I was expressing an  
opinion about "the things that certain people with certain mindsets  
worry about and why GC upsets them".


You're right, it's not a .NET list.  But, Java and .NET programmers  
have been working in an environment very similar to that found in  
Cocoa, except that they've been exposed to garbage collection a lot  
longer than Cocoa-only programmers have been.  While this mailing  
list is for Cocoa topics, it's useful to take advantage of lessons  
learned in other frameworks when applicable, and it's definitely  
applicable here.


The problem with that is that those lessons do not apply to the Apple  
GC!   Fast generation-scavenging copying collectors achieve very  
different performance characteristics, they can allocate objects  
order(s) of magnitude faster and incur no cost for deallocating young  
objects.  All that does not apply.


Cheers,

Marcel

___

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: GC pros and cons

[Marcel Weiher]

On Jun 24, 2009, at 22:49 , Greg Titus wrote:



...whereas this part talks specifically about the collector.  Is  
there a downside in SnowLeopard to CFRetain/CFRelease when not  
using the collector?


There's no _new_ downside to CFRetain/CFRelease. It's just the  
existing downside (collected process or not) that CFRetain/CFRelease  
are function calls that need to be made and code that needs to be  
executed,


You do realize that assignments under GC generate function calls?  So  
while you don't see them in your code, they still do get executed.   
And if you use accessors and let your accessors be generated (by  
@synthesize or accessor macros), the difference is negligible.


and, what's more, retain/release needs to be thread-safe, which adds  
a bit more to the expense.


Yep.

The important word in what Bill was saying is "concurrently". The  
garbage collector can work concurrently in another thread, so your  
tight loops in your compute thread(s) do less work (no CFRetain/ 
CFRelease)


My tight loops tend not to have retains/releases, because I tend to  
lift expensive operations out of performance-sensitive inner loops.   
But that's just me.


, and you get a performance advantage because your code is able to  
take more advantage of multiple cores, since memory is reclaimed in  
a separate thread, rather than that work being interleaved in your  
code in the compute thread(s).


That is a theoretical advantage (unless you are concerned about power  
consumption).  To be practical, the overhead of running the extra  
thread and the overhead of the in-thread GC code must be less than the  
overhead of RC.  Measurement helps answer that question.


Marcel

___

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: GC pros and cons

[Peter Ammon]

On Jun 24, 2009, at 8:11 PM, Kyle Sluder wrote:


On Wed, Jun 24, 2009 at 7:55 PM, Peter Ammon wrote:
Microsoft even says that all objects must be robust against being  
Dispose()d
multiple times, which smacks of sloppiness.  If your program  
disposes of an
object twice, then it is structured so that independent usages of  
the object
are not coordinated, and so it is likely that one part of your  
program uses

an object after it has been disposed by another part.


It's not really sloppiness.  Python behaves the same way with its
contexts; both Python contexts and Dispose() are intended to be used
on objects that hold on to finite resources.  Similarly to Dispose(),
you can't reopen a closed NSStream.

IOW, Dispose() isn't a memory management technique, it's a
limited-resource-management technique.

--Kyle Sluder



Are you saying that it's not sloppy to close a file twice, unlock a  
lock twice, etc.?


Python doesn't require that its contexts be robust against multiple  
calls to __exit__ (its answer to Dispose()).


___

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: GC pros and cons

[Peter Duniho]

On Jun 25, 2009, at 7:37 AM, Michael Ash wrote:


That may be the theory, Apple's ObjC collector does *not* trigger on
allocation errors (at least not reliably or sufficiently, and as such
it is possible to outrun the collector by creating a large number of
objects in a tight loop.


Well, as far as I'm concerned that's a bug then, and a somewhat silly  
one at that.  There should be no reason they couldn't easily address  
that scenario, simply by using the thread attempting to do the  
allocation to run the collection code (with the usual synchronization/ 
execution management that you'd need in any collection/compaction  
scenario).


But then, that just reinforces the point that the Obj-C/Cocoa garbage  
collection implementation has some refinement left to accomplish.  I'm  
glad to hear there've been bugs submitted on the issue; I expect Apple  
will address them eventually.  Until they do, people who say that GC- 
managed memory in Cocoa isn't quite fully baked yet will actually have  
a good point.  ;)


Pete
___

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: GC pros and cons

[Bill Bumgarner]

On Jun 25, 2009, at 9:50 AM, Michael Ash wrote:

Oh, forgot to mention, in case any Apple peoples are reading this and
interested in it (although I imagine that any who care already know),
this is filed as rdar://5563149 which is still open as of this
writing.


It'll be returned to you shortly as a duplicate of a bug that  
encapsulates a larger set of outrun-the-collector issues.


A number of these issues have been mitigated in SnowLeopard, but it is  
still possible to outrun the collector (and quite easy with  
pathological test cases, as you indicated).


In general (and for the benefit of the rest of the list), GC is  
optimized for best performance within a running application.  There  
are any number of pathological patterns -- micro-benchmarks, if you  
will -- that can demonstrate serious performance issues.   If you  
write one, please file a bug with it -- while the goal is real world  
performance, the team still does appreciate collecting edge cases and  
making them work better, too.


b.bum

___

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: GC pros and cons

[Michael Ash]

On Thu, Jun 25, 2009 at 10:37 AM, Michael Ash wrote:
> That may be the theory, Apple's ObjC collector does *not* trigger on
> allocation errors (at least not reliably or sufficiently, and as such
> it is possible to outrun the collector by creating a large number of
> objects in a tight loop.
>
> This program demonstrates the problem:
[snippity]

Oh, forgot to mention, in case any Apple peoples are reading this and
interested in it (although I imagine that any who care already know),
this is filed as rdar://5563149 which is still open as of this
writing.

Mike
___

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: GC pros and cons

[Michael Ash]

On Thu, Jun 25, 2009 at 3:54 AM, Peter Duniho wrote:
> In a GC system, the fact that an object hasn't been collected yet doesn't
> interfere with future allocations.  All it means is that the GC hasn't
> gotten around to collecting the object yet.  If and when a new object is
> required, and if the GC hasn't yet gotten around to collecting dead
> (unreachable) objects, and if there is not enough space to fulfill the new
> object, at that point in time the GC _will_ start working on collecting dead
> objects.
>
> You're not going to see a memory allocation failure simply because of
> non-determinism in the garbage collector.

That may be the theory, Apple's ObjC collector does *not* trigger on
allocation errors (at least not reliably or sufficiently, and as such
it is possible to outrun the collector by creating a large number of
objects in a tight loop.

This program demonstrates the problem:

#import 

int main( int argc, char **argv )
{
objc_startCollectorThread();

while(1)
[NSMutableData dataWithLength:1];

return 0;
}

After a while it started to spew out errors like this:

a.out(78814,0xa0160720) malloc: *** mmap(size=125001728) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

I will freely admit that the above test program is a deeply
pathological case and you're highly unlikely to run into this in a
real application, however it is at least possible.

Mike
___

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: GC pros and cons

[Peter Duniho]

On Jun 24, 2009, at 9:15 PM, Jeff Laing wrote:


1. If your objects use (scarce) resources that are not themselves
subject to GC (file handles, network connections, whatever), you'd be

[snip]

2. If you expect objects to be returned to the free memory pool "the
instant that those objects aren't required" then GC isn't going to
satisfy you.

[snip]

However, in this case, it's the expectation that's unreasonable, not
GC behavior. You don't actually care that unreferenced objects die
instantly. You actually care than new objects can be created quickly.


Actually, I just care that they can be created at all.


Then Quincy's comments are ten times more true for your situation.  :)

In a GC system, the fact that an object hasn't been collected yet  
doesn't interfere with future allocations.  All it means is that the  
GC hasn't gotten around to collecting the object yet.  If and when a  
new object is required, and if the GC hasn't yet gotten around to  
collecting dead (unreachable) objects, and if there is not enough  
space to fulfill the new object, at that point in time the GC _will_  
start working on collecting dead objects.


You're not going to see a memory allocation failure simply because of  
non-determinism in the garbage collector.


Furthermore, it is more typical that there _is_ space already  
available on the heap to satisfy an allocation request, and in a  
typical GC system allocations are much faster than for the alloc/free  
paradigm.  I admit, I don't know the specifics of the Obj-C system,  
but in other systems an allocation is simply a matter of updating a  
_single_ pointer and of course there are no explicit deallocations at  
all.  An alloc/free generally involves a heap with a free list, where  
every allocation involves splitting a block, updating the free list  
and possibly other guard structures, and deallocations involve similar  
work but going the other direction.


GC systems, in my experience, tend to have more "jitter", due to the  
intermittent operation of the collector.  But they have the potential  
to be more efficient overall, depending on the implementation.


My situation is that "free memory is a scarce resource" for the  
class of applications that I'm working with, and there's no way that  
an IDisposable() can be bolted on to solve "memory" problems without  
completely replicating Release().


Even in .NET, IDisposable (which is an interface, not a method...the  
method is "Dispose()"), it's not a solution for memory scarcity  
issues, nor is there anything in the referenced article that suggests  
it is.  There's nothing one can do in a Dispose() method or finalizer  
to improve GC performance with respect to _memory_ allocations.  Those  
are there to help deal with unmanaged objects, including memory  
allocated via unmanaged techniques.


Obj-C 2.0/Cocoa has similar issues, and they are in fact addressed in  
similar ways.  The main difference I note is that because GC is a new  
thing for Obj-C, whereas it was there from the outset for languages  
like Lisp, Java, C#, etc. you have a _lot_ more situations where the  
boundary between "managed" (i.e. garbage-collected) and  
"unmanaged" (i.e. retain/release, never mind all the usual non-memory  
resources) is an issue, and there's less in the way of "collective  
wisdom" in terms of using the GC system.


Over time, I expect that to be much less of an issue.

Its not reasonable to say "but virtual memory will solve that  
problem" because it just won't.


Nobody's said that.  A GC system really has practically the same  
relationship with the virtual memory manager as the retain/release  
system.


My customers have terabytes of data any of which might be called  
into memory and cached there for performance reasons because we  
can't know when they are going to randomly access any of them, and  
the data is more complex than just a single row from a database table.


We aren't using "hanging around in memory" as our caching mechanism,  
we hold things in LRU chains and we uncache the oldest ones first.   
A GC solution that doesn't immediately free the object when we  
release it means that we need to manually poke the GC machine to get  
the benefit of the uncache, whereas if we *know* that it will  
deallocate objects when we tell it to, we're fine.


What "benefit of the uncache" are you referring to?  A delayed  
collection of the object isn't going to interfere with future  
allocations.  Is there some other "benefit" you're thinking of?


As has been pointed out, this isn't a .NET list, and I don't care  
strongly about this topic, except in as much as I was expressing an  
opinion about "the things that certain people with certain mindsets  
worry about and why GC upsets them".


You're right, it's not a .NET list.  But, Java and .NET programmers  
have been working in an environment very similar to that found in  
Cocoa, except that they've been exposed to garbage collection a lot  
longer th

Re: GC pros and cons

[Greg Titus]

On Jun 24, 2009, at 10:38 PM, Marcel Weiher wrote:


On Jun 24, 2009, at 11:00 , Bill Bumgarner wrote:


On Jun 24, 2009, at 12:51 PM, Quincey Morris wrote:
In a nutshell, for folks like me who regularly use CFCreate …  
CFRelease in loops, what are the benefits of GC?


If CFCreate/CFRelease is precisely what you want to do, there are  
no benefits from GC, because the garbage collector isn't involved.  
Similarly, if you regularly use alloc/init ... release in loops,  
there are no benefits from using autorelease instead of release  
(in a non-GC app, I mean).


However, if the lifetime of the object you CFCreate is not  
strictly internal to the loop, then using (in a GC app)  
CFMakeCollectable once instead of futzing with CFRelease in  
multiple paths of execution might simplify your code greatly.


There are actually some performance downsides to using CFRetain/ 
CFRelease in Leopard that grow to a greater significance in Snow  
Leopard.  In Snow Leopard, this includes short lived objects like  
the temporaries that may be CFCreate'd/CFRelease'd in a tight loop  
(obviously, I can't disclose what those changes are -- if you are  
curious, post a question to devforums.apple.com).


Hmm...this part of the answer indicates a generic downside...

Specifically, you are effectively disabling the Collector's ability  
to do collection work, including object reclamation and  
finalization, concurrently with the execution of code that actually  
does work.


...whereas this part talks specifically about the collector.  Is  
there a downside in SnowLeopard to CFRetain/CFRelease when not using  
the collector?




There's no _new_ downside to CFRetain/CFRelease. It's just the  
existing downside (collected process or not) that CFRetain/CFRelease  
are function calls that need to be made and code that needs to be  
executed, and, what's more, retain/release needs to be thread-safe,  
which adds a bit more to the expense.


The important word in what Bill was saying is "concurrently". The  
garbage collector can work concurrently in another thread, so your  
tight loops in your compute thread(s) do less work (no CFRetain/ 
CFRelease), and you get a performance advantage because your code is  
able to take more advantage of multiple cores, since memory is  
reclaimed in a separate thread, rather than that work being  
interleaved in your code in the compute thread(s).


- Greg___

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: GC pros and cons

[Marcel Weiher]

On Jun 24, 2009, at 11:00 , Bill Bumgarner wrote:


On Jun 24, 2009, at 12:51 PM, Quincey Morris wrote:
In a nutshell, for folks like me who regularly use CFCreate …  
CFRelease in loops, what are the benefits of GC?


If CFCreate/CFRelease is precisely what you want to do, there are  
no benefits from GC, because the garbage collector isn't involved.  
Similarly, if you regularly use alloc/init ... release in loops,  
there are no benefits from using autorelease instead of release (in  
a non-GC app, I mean).


However, if the lifetime of the object you CFCreate is not strictly  
internal to the loop, then using (in a GC app) CFMakeCollectable  
once instead of futzing with CFRelease in multiple paths of  
execution might simplify your code greatly.


There are actually some performance downsides to using CFRetain/ 
CFRelease in Leopard that grow to a greater significance in Snow  
Leopard.  In Snow Leopard, this includes short lived objects like  
the temporaries that may be CFCreate'd/CFRelease'd in a tight loop  
(obviously, I can't disclose what those changes are -- if you are  
curious, post a question to devforums.apple.com).


Hmm...this part of the answer indicates a generic downside...

Specifically, you are effectively disabling the Collector's ability  
to do collection work, including object reclamation and  
finalization, concurrently with the execution of code that actually  
does work.


...whereas this part talks specifically about the collector.  Is there  
a downside in SnowLeopard to CFRetain/CFRelease when not using the  
collector?


Marcel

___

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: GC pros and cons

[Jeff Laing]

> 1. If your objects use (scarce) resources that are not themselves
> subject to GC (file handles, network connections, whatever), you'd be
[snip]
> 2. If you expect objects to be returned to the free memory pool "the
> instant that those objects aren't required" then GC isn't going to
> satisfy you.
[snip]
> However, in this case, it's the expectation that's unreasonable, not
> GC behavior. You don't actually care that unreferenced objects die
> instantly. You actually care than new objects can be created quickly.

Actually, I just care that they can be created at all.  My situation is that 
"free memory is a scarce resource" for the class of applications that I'm 
working with, and there's no way that an IDisposable() can be bolted on to 
solve "memory" problems without completely replicating Release().

Its not reasonable to say "but virtual memory will solve that problem" because 
it just won't. My customers have terabytes of data any of which might be called 
into memory and cached there for performance reasons because we can't know when 
they are going to randomly access any of them, and the data is more complex 
than just a single row from a database table.

We aren't using "hanging around in memory" as our caching mechanism, we hold 
things in LRU chains and we uncache the oldest ones first.  A GC solution that 
doesn't immediately free the object when we release it means that we need to 
manually poke the GC machine to get the benefit of the uncache, whereas if we 
*know* that it will deallocate objects when we tell it to, we're fine.

As has been pointed out, this isn't a .NET list, and I don't care strongly 
about this topic, except in as much as I was expressing an opinion about "the 
things that certain people with certain mindsets worry about and why GC upsets 
them".

___

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: GC pros and cons

[Chris Idou]

On Jun 24, 2009, at 18:19, Jeff Laing wrote:

> we regularly cache hundreds of thousands of objects from a persistent 
> (relational) store and it is absolutely critical to us that the instant that 
> those objects aren't required, they give their 
> memory back - that's how we can run in a machine with only(?) 1 gig of ram.  
> So I'm one of those people I mentioned earlier that really really cares that 
> cleanup happens as soon as 
> possible, not 

That's the kind of scenario where an object database usually has the correct 
semantics. Objects are created in a pool, and usually you want them all freed 
when the transaction ends.

Still, I don't see why GC wouldn't also work. People seem to have a perception 
that GC programs must always be bloated and late in cleaning up. That's 
probably not a correct assumption.


  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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