Comment by bjourne | Hacker News Reader

Comment by bjourne | Hacker News Reader

> do something with garbage collection (but what? I’m confused about this still.)

It's an almost hilarious technique. In a garbage collected, multi-threaded virtual machine the runtime may at some point decide it is time for garbage collection. However, all threads must first be stopped because allocating memory while the garbage collector runs leads to badness and/or the garbage collector moves objects referenced by threads.

There is no direct way to signal to a thread that it should stop and having the thread poll some flag would hurt performance. Instead the compiler inserts dummy instructions (safepoints) at the top of every loop body or function entry point which writes to a page the runtime controls:

    mov  [addr], eax

Then when it's time to stop all threads, it just write protects the page! Every thread eventually stumbles upon the bomb. Boom! SIGSEGV! Boom! SIGSEGV! Boom! When every thread has exploded the garbage collector can run in peace. Then the runtime removes the write protection and resumes executing all threads. Something very similar is used on Windows (though I think it's called events and not signals) and sometimes you use read-protected pages rather than write-protected ones, but the principle is the same.

You probably want to read and not write, as writing will cause a lot of cache ping-pong and slow the mutator down when it doesn't SEGV on the dummy access <https://users.cecs.anu.edu.au/~steveb/pubs/papers/yieldpoint...>

Have you got any links to how they continue the threads after the gc has run? I was looking for something similar but couldn't find much.

Naïve approach is to have each segv handler poll something to tell when GC is done, and simply return when it can. State is then restored by the kernel.

You could have each thread select(), poll(), or read() a byte, from the same pipe in their SIGSEGV handler. (Those syscalls are async-signal-safe in POSIX.)

When it's time to resume, the GC unprotects the page then writes a byte (or enough bytes if read() is used), which wakes all the blocked mutator threads.

Those threads also need to synchronise acks with the GC. After the GC protects the guard page, the mutators don't stop mutating immediately, so they must send an ack to the GC thread from their SIGSEGV handler to say when they have stopped. A pipe can be used for this too. Use of a non-mutex-using atomic counter, if available, can speed this by ensuring the GC only wakes once. Similarly the mutator threads must send an ack after they resume before returning from their SIGSEGV handler, to ensure the next GC run does not race with a mutator thread still slowly handling the current GC run

On Linux, futex or eventfd are async-signal-safe but non-portable alternatives to pipes. Futex has the advantage of not using a file descriptor and may be faster.

Reply on news.ycombinator.com