Thanks for the info! I will for sure take a look before submitting my proposal
On Wednesday, February 1, 2017 at 5:34:53 PM UTC-8, Keith Randall wrote: > > &$*@^! Google! Apparently "publish to the web" doesn't mean publish to > the web when you're inside Google. > > But I can publish to a pdf and then attach it... > > On Wed, Feb 1, 2017 at 5:24 PM, Caleb Spare <ces...@gmail.com > <javascript:>> wrote: > >> Your document is not accessible to me. (Google-internal?) >> >> On Wed, Feb 1, 2017 at 5:18 PM, 'Keith Randall' via golang-nuts >> <golan...@googlegroups.com <javascript:>> wrote: >> > 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> 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...@googlegroups.com <javascript:>. >> > For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
