Gc.set now changes the minor heap size of all domains#11142
Gc.set now changes the minor heap size of all domains#11142sabine wants to merge 1 commit intoocaml:trunkfrom
Conversation
b17f970 to
a723b64
Compare
a723b64 to
703c990
Compare
Every call to `Gc.set` that modifies the minor heap size causes a stop-the-world section, in order to adjust the minor heaps of all domains. On `domain_terminate()`, we free the minor heap to maintain the invariant "only active domains have a minor heap allocated". Resulting simplifications: we no longer keep track of individual domains' minor heap size - instead, we have a global variable `caml_minor_heap_wsz` for the size of the minor heap, and every domain allocates a minor heap of this size. This patch resolves the FIXME from ocaml#11082 relating to the duplicate reallocation of the leader domain's minor heap.
703c990 to
f573882
Compare
|
Here is what I understand about the proposed implementation (I wasn't involved in writing the code of this one PR and could review the implementation) is that:
On the current trunk, we would reserve the same memory size for all domains, but each domain can allocate a different size. Here all domains must allocate the same size. I could see this being an issue in heterogeneous workflows when the "main domain", doing most of the work, uses an in-fact-fairly-large minor heap, but we still want "auxiliary domains" around to, say, offload serialization/logging tasks, and for those we don't want a large minor heap. Note that it would be possible to provide the feature of this PR, that is an ability to set all the minor heap size for all domains at once, and also the minor heap of future domains (which I think we want in any case), while preserving the ability to set different minor heap sizes for specific domains. But then:
|
|
You're correct: whether we want all the simplifications of this PR is not necessarily a given - the current design (reserving, and then allocating a minor heap up to the size of the per-domain reservation) allows for use cases where the memory load is not evenly distributed. As I understand it, extending the UI for minor heap resizing is a post-5.00 feature.
Indeed, and it's not immediately obvious what a good extended UI looks like. I opened a discussion at #11156. For the 5.00 release, the simplifications are attractive in the sense that they reduce code complexity, for the time being. But indeed, when we want to support heterogenous workloads on the minor heap by letting every domain control its own minor heap allocation size, we will have to add most (but not all) of this complexity back. I wanted to see what the differences were, and in that sense this experiment has been useful. |
Currently, every domain has its own minor heap size that it can modify within the boundary of the minor heap reservation. However, this semantics of
Gc.setmay be confusing to the user.This PR proposes to adjust the semantics of
Gc.setand simplify the minor heap allocation code (with the intent of keeping minor heap allocation code complexity as low as we can for the 5.00 release):Gc.setupdates the minor heap size for all domains.Caml_state, we make the minor heap size global.minor_heap_area_startandminor_heap_area_endindom_internal. Since access to these boundaries is not performance-critical, we can compute them from the minor heap size and domain index instead.domain_terminate()under the protection of the domain lock. This establishes the invariant that only active domains have a minor heap allocated (committed) within the minor heap reservation of all domains.In contrast to #11082, setting a smaller minor heap size also stops the world and makes a new minor heap reservation, as we adjust the minor heap size of all domains.
This patch resolves the FIXME from #11082 relating to the duplicate reallocation of the leader domain's minor heap.
As this patch implements the user-visible extension of
Gc.setsemantics for 5.00, we propose a sharedChangesentry for #11082 and this PR.