I've been meaning to look into it, so these are mostly notes, that others might find useful,
arenas are x86_64 only, not sure how involved are ports, but there's at least a VOP, that as of right now exists only on x86_64. (the build obviously fails on other systems)
I'm trying it on m1, so I can build with
arch -arch x86_64 sh make.sh --with-system-tlabs
and then run with
arch -arch x86_64 sh run-sbcl.sh
it's pretty raw, so for example allocating object larger than arena results in ldb. there's a lot of sample code in tests/arena.impure.lisp
and the simplest possible test code just to see what's up,
(gc :full t)
(room)
;;; 7,084,208 bytes for 36,307 simple-vector objects
(progn (make-array 10000000) (values))
(room)
;; 86,991,136 bytes for 36,080 simple-vector objects
(gc :full t)
;; 6,847,824 bytes for 35,865 simple-vector objects
(use-package :sb-vm)
(defvar a (new-arena 100000000))
(with-arena (a) (make-array 10000000) (values))
(room)
;; 7,050,080 bytes for 36,233 simple-vector objects
well, so at least we know the array is put somewhere. finally one calls (destroy-arena a), but you can still access the data, so presumably there's no checking involved, and being undisciplined about retaining arena pointers will create all kinds of interesting bugs.
neat!
arenas are x86_64 only, not sure how involved are ports, but there's at least a VOP, that as of right now exists only on x86_64. (the build obviously fails on other systems)
I'm trying it on m1, so I can build with
and then run with it's pretty raw, so for example allocating object larger than arena results in ldb. there's a lot of sample code in tests/arena.impure.lispand the simplest possible test code just to see what's up,
well, so at least we know the array is put somewhere. finally one calls (destroy-arena a), but you can still access the data, so presumably there's no checking involved, and being undisciplined about retaining arena pointers will create all kinds of interesting bugs.neat!