Do we have free bits in the info pointer itself?

[Reid Barton]

Good point. Also

* the high bits are free now, but they may not be free forever (though
that's not a great reason to avoid using them in the meantime)

* masking off the high bits when entering is rather expensive, at
least in code size, compared to a simple "jmp *%rax" or especially
"jmp *symb", which appears at the end of almost every Haskell function

* modifying the low bits of a pointer will leave it pointing at the
same cache line, so the hardware prefetcher may decide to prefetch the
contents (hopefully at an appropriate time) while modifying the high
bits will make it not look like a pointer at all. But it's hard to
know how much we currently gain from hardware prefetching, if
anything.

Certainly these downsides are not necessarily deal-breakers, as
demonstrated by NaN-boxing as used in major JavaScript engines.

What did you intend to use the high bits for?

Regards,
Reid Barton

On Wed, Sep 7, 2016 at 11:16 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Mostly just that GHC still works on 32 bit platforms.
>
> -Edward
>
> On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>> Our heap object header is one word -- an info table pointer.
>>
>> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside
>> the object header for other purposes, right?
>>
>> Is there any problem with using these other than having to mask the info
>> table pointer each time it is dereferenced?
>>
>> Thanks,
>>   -Ryan
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>