This was accessible and interesting, thanks for the link.
A few questions:
1. Does the overhead of creating a new CLH every time a Haskell function is invoked from C introduce any performance concerns(speed didn't seem to be well-covered in section 6)?
2. How should Table 5 be interpreted? Is the main goal to show that B5 and B6 do not use the garbage collector if it's unnecessary for the task? Not sure I understand how the event-driven mutator fits into the situation.
> 1. Does the overhead of creating a new CLH every time a Haskell function is invoked from C introduce any performance concerns(speed didn't seem to be well-covered in section 6)?
Yes. It needs to initialize the heep at any function entry point. The time is proportional to number of all thunk on the Haskell application.
However, in future design, we may cache the initialized heap structure.
> 2. How should Table 5 be interpreted? Is the main goal to show that B5 and B6 do not use the garbage collector if it's unnecessary for the task? Not sure I understand how the event-driven mutator fits into the situation.
Yes. Interrupt occur on Table 5.
B5 and B6 are also using GC. However, GC trigger doesn't occur while the Haskell contexts are live, because the context's heap is big enough to escape first GC trigger watermark.
Excited to see more haskell work in embedded systems