I wrote up a proto-proposal for something like this a while ago. https://docs.google.com/a/google.com/document/d/18nu6QTr-ACYr5AiyP6x31SkXvuJZZaZ12lnvPTEQfgQ/pub
It has a few numbers worth looking at in it. This proposal was before the fully precise GC we have today. It needs to have special GC marking bits for string pointer words (like we did for interface data words so long ago: go1.3ish). I'm not sure we could get it to work today. On Wednesday, February 1, 2017 at 10:46:05 AM UTC-8, Ian Lance Taylor wrote: > > On Wed, Feb 1, 2017 at 10:38 AM, Eliot Hedeman > <eliot.d...@gmail.com <javascript:>> wrote: > > Ok, I'm going to try to restate the issues raised and answer them one by > > one. If I misunderstand, please let me know. > > > > 1. The GC needs to know if a pointer is actually a pointer. > > Solution: Check if the high bit is set. If it is, you know for sure that > it > > is not a pointer. > > It actually doesn't matter if the cpu ignores the top 16 bits or not. > The > > point is that the top 8 bits will never be used in an actual pointer, > and > > that is all we care about for this implementation. > > It's not that simple. At least on Solaris amd64, the high bit will be > set for a pointer into the stack. > > > 2. This only works for x86-64 > > Solution: I don't even think it is hyperbolic to say that 99% of all go > > running in production is on x86-64. So even if this optimization is only > > implemented for x86-64, it is well worth it. The rest could be take care > of > > by a stubbed out isSmallString(s string) bool that always returns false, > and > > let the compiler remove all the small string code from the resulting > binary. > > I suppose we could do that but I would consider it very unfortunate. > > 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.
