I was just wondering about something right now. The original issue I thought using a uintptr would have over an unsafe.Pointer is because the Garbage Collector wouldn't associate it with an actual reference to an object and hence, if it was the the only reference to an object, it would get garbage collected. However, after recent digging, it turns out that the GC handles garbage collection (correct me if I am wrong, as I am making my argument/stance based on this "fact") by scanning slots for live-objects, wherein a slot is a pointer-size word-aligned contiguous region of memory in the heap. The GC maintains a bitmap to determine if an object is live by keeping 2-bits per slot and pretty much mapping them together.
What I mean by this is... imagine you have the following memory layout... [0xFF][0x32][0x03][0xA0] <- Pointer to some object [0x00][0x00][0x00][0x20] <- Integer which happens to be same size as a pointer [0xFF][0x32][0x03][0xA0] <- uintptr, the integer value of a pointer address [0xFF][0x32][0x03][0xA1] <- Address of the object but with it's LSB marked/tagged Does it determine whether or not an integer (such as a normal int, case 2, and a uintptr, case 3, and a tagged uintptr, case 4) points to an object as well to determine the liveliness of an object? Finally, is there any implicit overhead from casting to and from a uintptr (and unsafe.Pointer)? -- 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.
