10:39:48shka__cool article, didn't seen it on planet lisp https://medium.com/@MartinCracauer/llvms-garbage-collection-facilities-and-sbcl-s-generational-gc-a13eedfb1b31
10:56:31splittist(no, Medium, I will not pardon the interruption)
11:07:48beachI have doubts about the validity of the lessons to be learned from it.
11:08:26beachFor one thing the SBCL GC is not that great. It was written at a time when we talked very little about multi-core processors, parallelism, and concurrency.
11:09:26beachAlso, it seems that whenever I talk to SBCL maintainers about the GC, there are only two choices for finding GC roots: 1. Divide the registers into two sets, one set for pointers and one set for non-pointers, and 2. Conservative scanning of registers and stack.
11:10:19beachThis article adds a third choice, dictated by LLVM: For each FUNCTION, keep a stack map that gives the contents of registers and stack frames.
11:11:05beachThis LLVM choice is pretty much dismissed because "SBCL’s compiler can and does generate code that just places anything anywhere. This makes the stack a lot more compact in some call patterns."
11:11:53beachBut there is an even better choice: make a stack map not for each function, but for each PC value where the GC can be called.
11:12:06beachThat choice does not seem to occur to anybody.
11:19:28beachAlso, fast memory writes and no need to annotate write instructions, but whenever the write barrier is tripped, the cost has got to be huge, given that it is handled by an OS signal.
11:19:57beachI would like to see a benchmark of the comparison between the two methods. I know, it is hard to benchmark GC techniques.