Hi Emery and Martin,
thank you both for your answers! It makes sense to restrict the API for
portability and to keep the complexity low. However it feels kind of sad
to disable all the nice features of the runtime like concurrent and
parallel GC ;) But then parallelism can be achieved by using many small
Solo5 instances...
Regarding your GC implementation questions, I don't know much about GCs
so
can't comment. There are various OCaml people on this list so someone
may
be able to help or pass on your question to the compiler folks.
I would appreciate if someone comments on how the incremental Ocaml GC
on Solo5 splits the work. Right now I using fixed time slices for the
incremental GC by polling the timer, e.g., `while (timeout_tick() &&
!mark_stack_empty()) scan_next();` and `while (timeout_tick() &&
sweep_ptr < segment_end) advance_sweeping();`. timeout_tick only calls
the monotonic clock every few ticks based on an estimate when the
timeout is expected to have elapsed.
I have one unrelated question - the Solo5 API exposes the heap as one
continuous block of memory, where the stack is at the top. Is there some
way to ensure that the growing stack does not overwrite the heap, by
using some red zone pages? I can manually limit stack growth by limiting
recursion etc, but I would prefer to have physically enforced
guarantees. Would it make sense to change the API in such a way that
stack and heap are kept fully separate? For example at compile time a
fixed stack size is specified and the stack is kept at a different
location from the heap. The Solo5 API should then pass heap_start,
heap_size, stack_start, stack_size to the application.
Daniel
