radical ideas about GC and ARC : need to be time driven?

[luminousone via Digitalmars-d]

On Sunday, 11 May 2014 at 17:36:44 UTC, Manu via Digitalmars-d 
wrote:
> On 12 May 2014 02:38, Marco Leise via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> Am Sun, 11 May 2014 14:52:50 +1000
>> schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:
>>
>>> On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>> > On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand via 
>>> > Digitalmars-d wrote:
>>> >>  - Same question if D migrate to ARC?
>>> >
>>> > I highly doubt D will migrate to ARC. ARC will probably 
>>> > become
>>> > *possible*, but some language features fundamentally rely 
>>> > on the GC, and
>>> > I can't see how that will ever be changed.
>>>
>>> Which ones are incompatible with ARC?
>>
>> Pass-by-value slices as 2 machine words
>
> 64bit pointers are only 40-48 bits, so there's 32bits waste for 
> an
> offset... and if the base pointer is 32byte aligned (all 
> allocated
> memory is aligned), then you can reclaim another 5 bits 
> there... I
> think saving an arg register would probably be worth a shift.
> 32bit pointers... not so luck :/
> video games consoles though have bugger all memory, so heaps of 
> spare
> bits in the pointers! :P


I thought x86_64 pointers are sign extended? or does that just 
apply to real memory pointers and not virtual memory pointers?