>From what i read the top 16 bits in a pointer are generally not completely
ignored by the cpu in x86-64 virtual address space:
AMD64 Architecture Programmer’s Manual Volume 1 - 2.2.2 64-Bit Canonical
Addresses:
"Although implementations might not use all 64 bits of the virtual address,
they check bits 63 through the most-significant implemented bit to see if
those bits are all zeros or all ones. An address that complies with this
property is said to be in canonical address form. If a virtual-memory
reference is not in canonical form, the implementation causes a
general-protection exception or stack fault."
On Wednesday, February 1, 2017 at 7:59:45 AM UTC+1, Eliot Hedeman wrote:
>
> It may not be the most elegant solution, but you could possibly check for
> the high bit set on any pointer during GC. If the high bit is set, you know
> for sure that that pointer is not actually pointing to anything, but rather
> is data. Technically speaking, the top 16 bits of any pointer in x86-64 is
> completely ignored
> by the cpu, So To make this work, you would have to change the order of
> the stringStruct to be { len int, str unsafe.Pointer}, but the principle is
> the same, the last 8 bits could be used the exact same way.
> On Tuesday, January 31, 2017 at 9:15:54 PM UTC-8, Ian Lance wrote:
>>
>> On Tue, Jan 31, 2017 at 9:10 PM, Eliot Hedeman
>> <eliot.d...@gmail.com> wrote:
>> > I was writing up a proposal about adding the small string
>> > optimization(putting strings on the heap if they will fit within the
>> > sringStruct)to the go runtime, and I realized there might be good
>> reason why
>> > this has not been done yet. Are there any glaring reasons you can think
>> of?
>> > Here is the really rough draft of the proposal. Thanks for the
>> feedback!
>>
>> The problem is that the concurrent garbage collector needs to be able
>> to determine reliably and safely whether a word in memory, including
>> on the stack, contains a pointer or not. It's not OK to have a word
>> in memory that might or might contain a pointer. It's a good thing
>> that Go doesn't have unions in the language, because they would be
>> very difficult to implement in the garbage collector.
>>
>> Ian
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
