One thing that I didn’t get from the paper is how exactly
ConcurMinor
breaks the current FFI and the impact it would have on the existing eco-system, on a scale from “it affect all projects” to “only people doing that fancy thing” :–) ?
All the projects that use the C API. The details are here: C API changes · ocaml-multicore/ocaml-multicore Wiki · GitHub
At the end of the paper it seems you make the point that
ParMinor
is the solution to go with for the time being. Does this means you are going to leave behind the work done onConcurMinor
or do you intend to continue to maintain it ?
We don’t intend to maintain it. It is quite a bit of work to maintain and port the changes across two different GCs. ParMinor
GC is now at 4.11 branch point (the default multicore compiler is 4.10 + ParMinor now). The ConcMinor
is at 4.06.1.
Given that ConcMinor
breaks the C API, the ecosystem would have to be fixed for ConcMinor
to be useful. The code changes are indeed intricate; the differences are not just in the minor GC, but the compilers internal use of the C API. It will be quite a bit of work to keep both GCs in the same source distribution.