Re: Efficient object wrappers and GC
Re: Efficient object wrappers and GC
- Subject: Re: Efficient object wrappers and GC
- From: "Michael Ash" <email@hidden>
- Date: Fri, 11 Apr 2008 16:15:36 -0400
On Fri, Apr 11, 2008 at 12:53 PM, Alastair Houghton
<email@hidden> wrote:
> On 11 Apr 2008, at 16:07, Michael Ash wrote:
> > On Fri, Apr 11, 2008 at 6:04 AM, Alastair Houghton
> > <email@hidden> wrote:
> >
> > > Under GC, these kinds of tricks are no longer possible because there is
> no
> > > -retain call any more, so no way to tell if it is safe to re-initialise
> and
> > > return the same wrapper object.
> > >
> > > Aside from re-implementing the data structure itself in ObjC and making
> all
> > > of its nodes objects, which might not be possible in some cases, has
> anyone
> > > thought of an efficient solution to this problem when running under GC?
> > >
> >
> > The obvious technique would be to stop trying to make the optimization
> > implicit and to make it explicit and managed by the caller instead. In
> > other words, you write your API so that it explicitly returns the same
> > object every time you call -nextObject, just with a new state. Then
> > you have a copy method which the caller can use to get a new
> > unchanging object for the case where he wants to keep one around.
> >
>
> Yes. It's a shame though because that doesn't really fit with the way
> people expect NSEnumerator to behave.
Honestly the original one doesn't fit either. I expect this code to work:
id a = [enumerator nextObject];
id b = [enumerator nextObject];
assert(a != b);
(Except, of course, for cases where the collection actually does hold
two copies of the same object.)
The very nature of this optimization is such that it's going to
require the calling code to conform to it. The nature of that
conformance varies slightly under GC and under the traditional rules,
but it's there in both cases.
Technically the above may not be legal under the traditional rules
either, depending on how you interpret them. The scenario is similar
to the getter/setter problem of whether an object returned from a
getter is still valid if you then call the setter. But I think the
expectation here is that the object should remain valid even if it may
be technically legal to destroy it.
> I was really just wondering if someone else had had some stroke of genius
> and come up with a way to do this kind of thing under the GC. Or if,
> perhaps, it would be worth asking for some new feature as part of the GC to
> help with this kind of problem.
I think it's inherently not possible to do without destroying the
speed you're trying to gain. Due to how Apple's collector is
implemented, not generating write barriers for stack values, seeing if
an object has been stored requires re-scanning all dirty parts of the
stack.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden