On Mon, Aug 20, 2018 at 2:49 PM 'Florian Uekermann' via golang-nuts < golang-nuts@googlegroups.com> wrote:
> ... which would put unnecessary strain on the GC iirc, because the memory pointed to would be scanned conservatively (basically assuming everything in there could be a pointer). The garbage collector does not care about the values of items of a []T when T is not a pointer type nor a type containing transitively any pointers. However, do not play games with fake lengths and/or capacities of a slice, namely setting them to a larger than actual value. Go supports interior pointers pointing inside allocated memory blocks and the mechanism implementing this feature could be easily tripped by such invalid values in the general case, event though possibly not for a particular Go compiler. An easy way how to avoid any nasty interactions with the runtime is to manually allocate/deallocate memory holding the bit array. See for example: http://github.com/cznic/memory. I'd use the uintptr returning variants making GC absolutely uninterested in the value. Any for the pointer arithmetic you have to perform the calculations on uintptrs anyway. However, do you already have a positive proof that the bound checks are substantially expensive in your use case? I'm not saying that's not possible, but I'd guess it's not much probable in many, if not most realistic applications. Otherwise the code would have to access the slice most of the time doing basically nothing else. That may happen in some benchmarks, of course. -- -j -- 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.
