Sorry for the late reply… The nice retrospective on region-based memory management you provide as your first link does a good job at explaining the drawbacks of region inference, which I understand are commonly considered show-stoppers for any application to OCaml (unpredictability, lack of solution for separate compilation…). Even if one gives up on the idea of region inference, the idea of region (or arena) allocation does not quite fit the proposal, given that a lot of expressiveness comes from the hypothesis that you can move resources. So I do not think that their benchmarks are meaningful for this proposal, given that it does not contain anything as efficient as deallocating a whole arena at once.
Interested people can find slides from my talk from Monday at Inria Paris (updated to take feedback into account).
6 Likes
@gadmm on slide 35 it’s better to present a direct link . I had some issues with googling the italic text.
Ah, you have a right paper in the end…
I’m not going to pretend like I’m an expert here.
Most of the criticisms of region based memory allocation are that it’s prone to space leaks, and most languages don’t have the type system to support it, and the performance boost while significant isn’t worth all of the issues it brings, so like while it should be an add on library, or .
Those two issues, often force implementers to use it along with GC.
A bit late to the party, but a couple of years ago I played around with (ab)using the minor heap to implement something like region-based memory management. I don’t have access to the code anymore, but could probably recreate it if there was any interest?
2 Likes
Don’t ask me. Maybe @gadmm might be interested.
I sometimes care about parallel programs (to crunch numbers faster on multicore computers); I never care about concurrency (Lwt and Async users).
Cf. https://github.com/UnixJunkie/parany
My hunch is that a region-based GC could be useful for parallel programs in OCaml.
I.e. a shared memory region, write-once-read-many, is declared.
A owner process fills it (the only allowed writer for this shm).
Reader processes might read it several times.
Once all readers have finished reading (some synchronization mechanism is necessary somewhere), the owner can reuse the whole region for another iteration.
I.e. this region does not need a regular GC; the goal being low latency for parallel programs
exchanging messages.
Currently, something like this can be done using a bigarray, but I suspect performance could
be better if things did not need to be marshalled/unmarshalled to/from a bigarray. The parmap library uses this bigarray trick.
I.e. this “shared memory GC” needs to be able to write any regular OCaml value in there, and there need a functionality to copy-and-read out of it (for readers).
This being said, there are some functionalities like this in the ocamlnet library.
Also, currently the scalability of ocaml programs using parmap or parany is quite good.
That would just shave a few cycles more, and make parallelism scale better for finer grain computations.
2 Likes
Hack_parallel kind of fits your use case, though like the bigarray trick, there’s a whole lot of (de)serialization going on. IIRC, the (de)serialization has a significant performance impact, which prompted my experiment with (ab)using the minor heap as a region, as well as integrating something like the Ocamlnet functionality instead of marshalling the values.
I’ve chatted to @gadmm about this (I’ve vaguely been working with them on making off-heap values more first class, though ‘working’ is a stretch for what I’ve actually done).
1 Like
Hack_parallel is an ugly hack with an even uglier interface.
I’ll stay with my parany library for the moment, since it fills all my parallel needs.
Agreed that it’s not pretty - was mainly referring to the functionality 