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 <javascript:>> 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.
