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 [email protected].
For more options, visit https://groups.google.com/d/optout.
