On 08/18/2015 08:24 PM, shenanigans@sonic.net wrote:
- As with Erlang/BEAM: when sending messages across cores, *copy*
rather than share data for better cache locality. Of course, the Lispy approach would probably be to allow copying *or* sharing, and a thin package on top of something like SBCL's sb-concurrently (with an optional parameter to override) could enforce the recommended approach. Caveat below.
One of the larger issues I had with Erlang was that you couldn't sic a bunch of threads on analyzing or searching immutable multi-GB raw data structures (not ETS entries, nor hacking around with byte blobs).
My ideal layout would involve per-process heaps, with the option to either cons into or copy into the immutable shared heap. I believe collecting a shared add-only immutable-data heap in this form might not require stopping the world. As was mentioned elsewhere, however, designing around immutability advantages does venture further away from Lisp's style. Splitting memory into per-process heaps, shared immutable heap, and a shared mutable stop-the-world-to-GC heap might be going a little overboard, especially since the allocation/copy style generally has to be declared by the human.