(1/2)
On Apr 3, 2005, at 2:43 AM, Marcel Weiher wrote:
[ -setVarAndRelease: ]
This example still requires an implicit retain in the object
allocation routine and a release in the -setVarAndRelease method.
Beside that, this setter does not follow the standard Cocoa
conventions for setters.
Sure it does, unless you mean the autoreleasing accessor nonsense.
There is -(void)seVar: and an *additional* -setVarAndRelease:, which
is a convenience for setVar:aVar and [aVar release];
I certainly would never implement such a setter in a framework which
may be used by other developers, because it would be a de facto given
that those poor developers would overlook the special semantic of
such a setter and end up with a buggy application.
The -setVar: accessor has completely standard semantics, whereas
-setVarAndRelease: is about as obviously named as you can get.
[more of the same deleted]
[inline reference counts]
It was certainly the case that up until the time frame of Rhapsody
DR2, some of the Foundation classes stored the reference count
inline. However, today thats no longer the case and even back then
you could count the classes that did this on one hand. Only classes
which are toll free bridged to CoreFoundation equivalents store a 15
bit inline reference count.
Well, that would be the vast majority of objects, wouldn't it?
Furthermore, a good number of other Foundation classes also have inline
refCounts.
However, I don't see the point why I should spend even more time for
basic stuff like efficient memory management that should be provided
by the language and framework out of the box. After all thats why we
use a framework - to reduce, if not remove altogether boring and thus
likely bugs causing repetive work.
Precisely. That's why I implemented this *once* and afterwards reused
that implementation. I also made that implementation OpenSource so
others could also reuse it.
I don't see that an efficient write-barrier is necessarily simpler
than -retain, but that aside, a check of the write barrier has to
occur on every pointer store, and for the AGC to be reliable, this
has to be enforced by the language. Apart from the impacts on code
size and performance, I just don't see how such a language can be
Objective-*C*.
No, going through a write barrier is only necessary for
non-initializing pointer stores where the pointer may cross a
generation boundary. It is not necessary otherwise. Luckily, it turns
out that most pointer stores are of the initializing type. I.e.
storing a pointer into a freshly created ObjC object is an
initializing store, loading a pointer into a scratch register is an
initializing store, or copying a pointer into a stack slot.
How does an Objective-C method know what is an "initializing pointer
store" and what is not? -init and friends are normal methods, can use
accessors to do their work, can be sent after the object has been
initialized, can be overriden.
The compiler can detect the cases where a pointer must go through a
write barrier and generate the necessary code in that cases.
How?
It can leave out aka optimize away the write barrier stuff in all
other cases. This is the big advantage of making AGC an integral part
of the language. It allows us to take advantage of all the knowledge
that a compiler builds up about a program it is compiling in order to
make AGC more efficient.
An Objective-C compiler has virtually no knowledge about the program it
is compiling.
[more implementation details of write barriers]
[Apple can call anything they want Objective-C]
Yes, a copying collector is not suitable for C based languages.
Good, then let's not bring up the advantages of copying collectors
Speed of allocation is obviously very important for an object
orientated language like ObjC. This is especially true for objects
which are used for a very short amount of time - aka temporary
objects.
Of course, there are ways of cheaply providing temporary objects,
such as an MPWObjectCache, especially effective if used in a "push"
fashion.
Provided, that I spend extra time on implementing such a caching
scheme that is often only effective for objects of a particular class
or object size.
Well, I just reuse such a caching scheme, and so can others...it's that
'reuse' thing again...
OO languages, however, have the tendency to generate a lot of such
objects. That is why for example the concept of generational GCs
was developed. Those AGCs take advantage of the fact that the vast
majority of objects typically created in an OO language are very
short-lived.
Hmm...I don't think the object allocation statistics for Smalltalk
and those for Objective-C are comparable.
Obviously, a typical Smalltalk application creates even more objects
than a typical ObjC application.
Exactly. And the AGC methods for these types of languages are "tuned"
for these types of object allocation profiles. The fact that such
techniques work well for those languages cannot be assumed to mean that
they will work well for languages with other allocation profiles.
Marcel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
