OCaml 5 GC. Releasing memory back to the OS

Learning
,
16

Thanks so much for running these and it’s good to see it had an impact.

It took a little while to get these branches running in the benchmarking suite (and there’s still an abort in one of the parallel benchmarks I need to investigate) but there’s some preliminary sequential numbers here:

https://sandmark.ocamllabs.io/?app=Sequential+Benchmarks&sequential_10=5.0.0%2Btrunk%2Bsequential&sequential_01=20230209&sequential_B2=navajo_5.0.1%2Btrunk%2Bsadiqj%2Bpool_release%2Bsequential_20230209_pool_re&sequential_11=20220322&sequential_02=navajo_5.0.1%2Btrunk%2Bsadiqj%2Bpool_release%2Bsequential_20230209_pool_re&sequential_00=5.0.1%2Btrunk%2Bsadiqj%2Bpool_release%2Bsequential&sequential_12=navajo_5.0.0%2Btrunk%2Bsequential_20220322_7130374&sequential_B0=navajo&sequential_B1=20230209&sequential_num_variants=2&sequential_find_by=variant

It seems the performance impact of not batching pool allocations is fairly small. The only difference between pool_release and pool_release_cycle is when pools are released. The former does so immediately, the latter only at the end of a major cycle.

I think there’s probably a good argument for releasing pools when done with them. I’m also pondering whether we need to mmap the pools or whether malloc might be sufficient.

2 Likes