Hi Kevin,
> Eventually, I ran into memory management/GC issues
> ...
> I was reading about memory management in Lisp Machines back in the day, and
> they used a concept called "areas" consisting of "regions" (the meaning of
> those terms, including "arena" and "pool"
PicoLisp doesn't use such areas, because it does not need them due to the single
(and single-(cell)-sized) internal data type.
I do not understand what you exactly need, but it may well be that you have
preliminary worries about gc. At least I would not worry or even think about the
garbage collector in such an early stage, it is very fast in PicoLisp (a
fraction of a millisecond per megabyte).
> * Is there any particular reason, such as for convenience or preventing
> fragmentation, that CELLS is defined rather than a variable?
It is just that heap chunks are convenient if they have a size of 1 MiB, but
otherwise almost *any* value for CELLS is OK. In the first versions of pil (Mac
II) it was only 32 KiB, . You won't notice any differences if you vary that
value,
so why make it a variable?
> * Is it possible to add a hook for when the GC is called? This would assist
> in profiling and diagnostics.
Yes. But still, what profiling and diagnostics? Where are the
bottlenecks?
> I believe memory management need not be a dichotomy between malloc/free and
> GC; tools can be provided to work in the grey space, which typically is
In pil you can do that with native calls
(let Buf (native "@" "malloc" 'N 1000000)
...
(native "@" "free" NIL Buf) )
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
