# Compaction discussion

**Date:** April 26th - May 2nd
**Location**: OCamllabs Slack, channel #compiler

- *Kate*
what is the current plan to enable compaction by default in 5.x? The changelog for 5.2 says that's not enabled by default and that calls to Gc.compact have to be done explicitly but i haven't seen any public plans to reintroduce implicit calls to it. Given 5.5 is on a path to replace 4.14 according to the release-info doc, is the reintroduction a plan for 5.5?

- *dra27*
I'm not sure that automatic compaction is regarded as a necessity at this stage (@sadiq?). That said, as ever, if there's a workload/application where the lack of automatic compaction is a problem, then that should be reported
The "waters are murky" where memory usage in 5.x is concerned at the moment, as the GC pacing changes which have been being worked on by Damien, Stephen & Nick at JS aren't in 5.4 - I would hypothesise that there are programs at the moment which are using much more memory (than in 4.x) where the GC pacing fixes may fix the problem (i.e. if the pools are never allocated in the first place, they don't need to be released)

- *mshinwell*
The GC performance is very much more satisfactory with those patches, fwiw
(they also have automatic compaction)

- *kc*
I didn't know that the automatic compaction bits were there. Would be great to get them into 5.5 along with the pacing fixes. (edited)

- *mshinwell*
Indeed, @stedolan and @Nick Barnes should advise about that
depending on timescale I would argue they should be in 5.4, the existing behaviour is much worse than runtime4 otherwise (although these patches also fix some things which were bad in runtime4 too)

- *kc*
The mark delay patches haven't landed yet. IIUC, there are still some rare issues with failures in multicoretests which we haven't fixed. (edited)

- *mshinwell*
Ah yes true, there might be some dependency there. We're about to look at those internally again actually

- *kc*
https://github.com/ocaml/ocaml/pull/13580

- *mshinwell*
Probably 5.5 then

- *kc*
Yeah.

- *mshinwell*
One main outcome is really that space_overhead actually responds nicely now (edited)

- *stedolan*
Yeah, there's a fiddly issue with handover of finalisers during domain termination that we need to fix before getting mark delay in. (It's probably a couple of hours work)

- *stedolan*
The other patches are smaller than that one

- *sadiq*
I'm still a bit concerned about the cost of compaction when done automatically.

- *Kate*
is it that much higher than on 4.14?

- *sadiq*
And if we're adopting the compactor from JS OCaml then it's more expensive.

- *Khady*
Even if it’s expensive, I’d argue it’s better to have compaction enabled by default, and let experts disable it or decide when they want it to run. For anyone who isn’t an expert in the Ocaml runtime, not having compaction by default is going to be a bad surprise

- *sadiq*
I think the way forward is probably to wait for the GC patches from JS to land upstream, then test out compaction on some moderately sized programs to understand what the impact on latency might be.
My concern is mostly inflicting unpredictable multi-second pauses on users.

- *Kate*
multi-second? O_O damn, is it really that bad? If it gets bad for some of the rare users that use GBs of small chunks of various sizes or something like that, i'm guessing they can always use the new Gc.ramp_up or anything similar that would just disable compaction

- *Yaron Minsky*
FWIW, Leo has made the argument that compaction should be off by default, and only invoked explicitly. I think this is pretty compelling once you have a less fragmentation-happy GC. Both best-fit and runtime5 have better fragmentation behavior, and we've had pretty good luck running lots of applications with compaction turned off.

It's just not good behavior for your program to check out for several seconds while it compacts. Programs that are at all interactive shouldn't do it at random points if they can at all avoid it.

I believe we turned it back on for backwards compatibility reasons, but longer term, we'd like to turn it back off. Given that the upstream world has already turned it off, I'm not at all sure we should make the change of turning it back on.

- *dra27*
@sadiq has talked in the past about using runtime events as the foundation of something akin to Java's "flight recordings" - having a toolset you can plug-in to any running OCaml application which can then provide heuristic judgements about how it's performing. One could well see that one of those heuristics as being "your program's execution profile looks like it might benefit from running compaction"