Hacker News Reader

Comment by masklinn | Hacker News Reader

> And since there are all kinds of pointers in D, one no longer can use a moving GC allocator, because it cannot know exactly where 100% of the GC pointers are.

Go's GC is non-moving and it can't safely be made moving in the current state[0].

It also used to be partially conservative until 1.3[1][2][3]: the heap was precise, but the stack was conservative.

[0] https://github.com/golang/go/issues/46787

[1] https://go.dev/doc/go1.3#garbage_collector

[2] https://docs.google.com/document/d/1lyPIbmsYbXnpNj57a261hgOY...

[3] https://docs.google.com/document/d/13v_u3UrN2pgUtPnH4y-qfmlX...

View on HN

It's also worth mentioning that being conservative only on the stack, even when moving, is often good enough. SBCL still works that way, and the space and time overheads are pretty tiny [0].

[0] Fast conservative garbage collection https://users.cecs.anu.edu.au/~steveb/pubs/papers/consrc-oop...

AFAICT pinning is temporary? E.g. even Java's native interface allowed pinning objects for a limited amount of time, which had to be incorporated into the design of Java's long series of GCs.

A historic mistake. These days a Java GC doesn't have to support pinning, and I don't think they do. Ctrl-F pinning at https://docs.oracle.com/javase/7/docs/technotes/guides/jni/s...

Erg, but soon the Virgil GC will have to support pinning, because you can directly call the kernel to do I/O with on-heap byte arrays. Currently I get away with that because Virgil is single-threaded only, but that's gotta change for Wizard to compete with more advanced VMs.

Memcpy is fast. Don't let them pin your arrays.

With syscalls you can mmap the ethernet controller's DMA region and write directly to it; zero copy to the wire and back. In Virgil, there's literally no restriction on what Linux syscalls you can do, so why not that too. Though, Range<byte> of off-heap memory (a new Virgil feature implemented with fat pointers), is probably better; you don't even have to leave the memory-safe core language to manipulate off-heap data.

Toit calls this external byte arrays, but whether it's a fat pointer or a small object is an implementation detail.

Reply on news.ycombinator.com