Dear all, I have some questions concerning the implementation details of the garbage collector regarding slices and arrays. I'm implementing bit slices. The current approach is to use the following struct: type BitSlice { data []uint64 len int } Given that the slices length and capacity are fairly useless to me (doing my own bounds checks on bit resolution anyway), I am considering two kinds of space optimizations using "unsafe". Unfortunately I don't know enough about how the garbage collector is implemented to judge if these optimizations are safe or not.
Option 1: Use the length or capacity to store the length of the bit slice. This is easy to do, but I worry about how the garbage collector interacts with len and cap. Question 1.1: Do I have to expect problems if I set the capacity to a larger value than the underlying array size or a negative value. Question 1.2: Is len used for anything but bounds checks? I assume no, so I could use that any way I want, as long as i don't perform an access that triggers a bounds check. Option 2: It may actually be easiest to use an array pointer instead. Like this: type BitSlice { data *[1<<((^uint(0))>>8)]uint64 len int cap int } In this case I would simply allocate using make([]uint64, desiredLength) and store a pointer to the underlying array in the data field. Question 2.1: Assuming I take care of bounds checks myself. Do I have to expect problems when I am storing a pointer to an array as a pointer to a larger array? Question 2.2: using an unsafe.Pointer as data field would trigger conservative garbage collection, correct? If anyone has any insights or smart ideas, I am all ears. Especially some opinions about option two would be appreciated, since I am favoring that at the moment. Best regards, Florian -- 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.