4 ms·

About untraced reference support is there something specific that you’re looking for? Although it doesn’t have a special type I’m pretty sure you can have regu

About untraced reference support is there something specific that you’re looking for? Although it doesn’t have a special type I’m pretty sure you can have regular Go object references / interfaces / arrays point to non-GC memory if you want (although you’ll have to cast the result from malloc or something similar). So most library functions should work with unmanaged memory OK by default (if they’re using standard slice/array types) which is not too bad as far as GC languages go.

pjmlp 6y ago
If you have explicit untraced reference support the GC doesn't have to guess and better algorithms can be taken advantage of. Without it, some guessing games might happen that bring everything down, or the GC has to be more conservative regarding its guesses. An example of this are the latest restrictions on Go 1.15 regarding pointer conversions https://golang.org/doc/go1.15#compiler https://golang.org/doc/go1.15#compiler
- throwaway34241 6y ago
  Wouldn’t the GC be able to just stop scanning memory once it encounters an off GC heap pointer (since it knows what address ranges it manages)? I’ve only allocated non-pointer-containing Go objects manually (that presumably wouldn’t be scanned anyway) and it’s hard to find the specifics of how things work, although it seems like there are some libraries that allow it. [1] Since it’s possible to use C data structures and pointers directly from Go that seems like the safest way to do it, although of course then you need a C toolchain installed. [1] https://github.com/teh-cmc/mmm https://github.com/teh-cmc/mmm
  - pjmlp 6y ago
    It is a bit more complicated than that, hence why conservative GC are pretty bad reclaiming memory, because they need to play safe. One of the reasons why they are changing the pointer rules in Go, was exactly because there are data races across domains if you happen to nest conversions between GC and non-GC pointers, and the GC happens to run just in the moment that it thinks the reference is no longer in use, while actually it was stored temporarily in an uintptr.

pjmlp 6y ago

If you have explicit untraced reference support the GC doesn't have to guess and better algorithms can be taken advantage of. Without it, some guessing games might happen that bring everything down, or the GC has to be more conservative regarding its guesses. An example of this are the latest restrictions on Go 1.15 regarding pointer conversions https://golang.org/doc/go1.15#compiler https://golang.org/doc/go1.15#compiler

throwaway34241 6y ago
Wouldn’t the GC be able to just stop scanning memory once it encounters an off GC heap pointer (since it knows what address ranges it manages)? I’ve only allocated non-pointer-containing Go objects manually (that presumably wouldn’t be scanned anyway) and it’s hard to find the specifics of how things work, although it seems like there are some libraries that allow it. [1] Since it’s possible to use C data structures and pointers directly from Go that seems like the safest way to do it, although of course then you need a C toolchain installed. [1] https://github.com/teh-cmc/mmm https://github.com/teh-cmc/mmm
- pjmlp 6y ago
  It is a bit more complicated than that, hence why conservative GC are pretty bad reclaiming memory, because they need to play safe. One of the reasons why they are changing the pointer rules in Go, was exactly because there are data races across domains if you happen to nest conversions between GC and non-GC pointers, and the GC happens to run just in the moment that it thinks the reference is no longer in use, while actually it was stored temporarily in an uintptr.