Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: Dave <email@hidden>
- Date: Wed, 11 Sep 2013 11:58:45 +0100
On 11 Sep 2013, at 05:04, Jens Alfke <email@hidden> wrote:
>
> On Sep 10, 2013, at 12:33 PM, Dave <email@hidden> wrote:
>
>> You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software).
>
> I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.)
This was using aUnix Box/MS-DOS box and it was our own hardware, and yes it worked with C and Assembler (via a set of Macro's). Basically it was a lump of hardware that controlled allocating memory from a pool. It wasn't used for system memory (although it could have been), but as a way of speeding up certain Image Processing operations. Basically it could allocate or free a memory block in one machine cycle - it could also copy or fill a block much faster then the CPU too.
>> If Apple were to implement something like this I think there would be a massive increase in performance and reliability
>
> Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it.
I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies).
> (This is a special case of the nearly universal engineer’s fallacy of dismissing any problem you haven’t personally worked on as trivial.)
I personally worked on these problems and I don't consider the trivial.
Cheers
Dave
_______________________________________________
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