3 ms·
> And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references. If the GC is o
by wtetzner 8y ago
> And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references.
If the GC is only triggered on allocations when there isn't enough free heap space, then why would stack scans happen at other times?
- monocasa 8y agoFor a driver, you have many contexts you're running. That's what the windows error "IRQL not less than or equal" blue screen means, that someone called a regular kernel function from within interrupt context. In drivers, you almost always heap allocate in your non interrupt contexts in order to dynamically handle load. This would be even more necessary in a unikernel, where you don't have a user space to defer that kind of work to. What I'm saying is that the necessary heap allocations happening in other contexts will block progress of your non allocating critical path, irq code on a GC based unikernel because of the need to discover liveness information. There are potential schemes to fix this, but they aren't implemented by MirageOS/OCaml, or most other managed unikernel environments I've seen.