freenode/#sicl - IRC Chatlog
Search
10:39:48
shka__
cool article, didn't seen it on planet lisp https://medium.com/@MartinCracauer/llvms-garbage-collection-facilities-and-sbcl-s-generational-gc-a13eedfb1b31
11:08:26
beach
For 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:26
beach
Also, 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:19
beach
This 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:05
beach
This 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:53
beach
But 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:19:28
beach
Also, 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:57
beach
I would like to see a benchmark of the comparison between the two methods. I know, it is hard to benchmark GC techniques.
11:38:02
beach
Yet another one: Apparently, the copying GC that SBCL uses must have been inconvenient for certain function object, so SBCL now has a special space for objects that don't move, presumably used for code. That space has a fixed size apparently, and this fact almost because a showstopper for SICL bootstrapping.
11:38:04
beach
SICL bootstrapping used lots and lots of FUNCALLABLE-STANDARD-OBJECTs and at some point, I ran out of space for those. stassats helped me out of my difficulty by having SBCL only allocate generic functions, and not all funcallable standard objects in that space, so I am saved. But the space is still there and it is still fixed size as far as I can tell.
11:41:45
beach
Let me get this straight, though. I am a very happy SBCL user. The maintainers are doing a fantastic job of keeping it correct, fast, and very useful. But I think the age is showing, which is why I am working on SICL. I may never finish without more help, but at least I have understood some aspects of what is needed.
11:46:24
beach
Things are a bit stalled right now for me, because I am working on this year's ELS submissions.
11:48:56
beach
I don't think the bootstrapping paper can be improved a lot more, so I am working on this one instead right now (warning VERY PRELIMINARY VERSION): http://metamodular.com/make-method-lambda.pdf