On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
> iOS now on 64-bit processors doesn't necessarily use a hashtable
> for refcounting. Basically, only 33 bits of the 64-bit pointer
> are used to actually refer to an address, then 19 of the
> remaining bits are used to store an inline reference count.

I am sure you are right, but how does that work? Do you have a link?

On Tue, 22 Apr 2014 13:22:19 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
>> iOS now on 64-bit processors doesn't necessarily use a hashtable
>> for refcounting. Basically, only 33 bits of the 64-bit pointer
>> are used to actually refer to an address, then 19 of the
>> remaining bits are used to store an inline reference count.
>
> I am sure you are right, but how does that work? Do you have a link?

I think what he's saying is the 19 bits are an offset into the global ref count container. Some sentinel value means "lookup the pointer in a hashtable."

-Steve

On Tuesday, 22 April 2014 at 17:22:21 UTC, Ola Fosheim Grøstad
wrote:
> On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
>> iOS now on 64-bit processors doesn't necessarily use a hashtable
>> for refcounting. Basically, only 33 bits of the 64-bit pointer
>> are used to actually refer to an address, then 19 of the
>> remaining bits are used to store an inline reference count.
>
> I am sure you are right, but how does that work? Do you have a link?

https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
Ctrl +F "Repurposed isa Pointer"

Details about isa structure:
http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html

On Tue, 22 Apr 2014 13:35:20 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 22 Apr 2014 13:22:19 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>
>> On Tuesday, 22 April 2014 at 16:58:23 UTC, Kapps wrote:
>>> iOS now on 64-bit processors doesn't necessarily use a hashtable
>>> for refcounting. Basically, only 33 bits of the 64-bit pointer
>>> are used to actually refer to an address, then 19 of the
>>> remaining bits are used to store an inline reference count.
>>
>> I am sure you are right, but how does that work? Do you have a link?
>
> I think what he's saying is the 19 bits are an offset into the global ref count container. Some sentinel value means "lookup the pointer in a hashtable."

Sorry, I was wrong. And so was Kapps, according to the article he referenced.

The 33 bits of the 64 bit pointer are used to point at a *class*, via the object's isa member. The other 19 bits can be used for ref counting. I mistakenly thought he meant the pointer to the object.

This is kind of weird though. Why do it this way? If there is such an advantage to having the ref count inside the object (and I don't disagree with that), why didn't they do that before? Surely adding another 32-bit field wouldn't have killed the runtime.

Even doing it the way they have seems unnecessarily complex, given that iOS 64-bit was brand new.

-Steve

On Tuesday, 22 April 2014 at 17:39:53 UTC, Kapps wrote:
> https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
> Ctrl +F "Repurposed isa Pointer"

Ah, ok, the refcount is embedded in the "class-table" pointer.

On Tuesday, 22 April 2014 at 17:52:28 UTC, Steven Schveighoffer wrote:
> Even doing it the way they have seems unnecessarily complex, given that iOS 64-bit was brand new.

I dislike this too… The only reason I can think of is that Apple themselves have code for OS-X that is optimized 64 bit code and that will break if they add another field? The lower bit is used for "compatibility mode". Hmm…

On 4/22/2014 2:20 AM, John Colvin wrote:
> A system that is automatically safe but can be manually managed for extra
> performance. That sounds very D-ish.

Needing to write @system code with a GC to get performance is rare in D. It's normal in O-C, as has been pointed out here a couple times.

On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright <newshound2@digitalmars.com>
> wrote:
>> The thing is, with iOS ARC, it cannot be statically guaranteed to be memory safe.
>
> So?

If you see no value in static guarantees of memory safety, then what can I say?

On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
> Again with the straw man!

If you really believe you can make a performant ARC system, and have it be memory safe, feel free to write a complete proposal on it.

On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>> The thing is, with iOS ARC, it cannot be statically guaranteed to be memory safe.
>>
>> So?
>
> If you see no value in static guarantees of memory safety, then what can I say?

Seriously, the straw man arguments have to stop.

There is plenty of valuable D code that is not guaranteed memory safe. For example, druntime.

ARC does not equal guaranteed memory safety. So NO, it cannot replace the GC for D @safe code. That doesn't make it useless.

-Steve