[r113500]

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!

[samus]

This is always the tradeoff with arenas. Either the runtime keeps it safe and postpones actually destroying the arena if there are references leading to it. Or it trusts the programmer, which will eventually result in fun late-night debugging sessions. TA indicates that SBCL is rather of the former variety since it describes debugging tools to find references leading from the heap to the arena.

I guess it is best practice to bury arena management inside some sort of framework* and don't fiddle with them in business code.

*: Edit: more likely, a macro