The comment in the manual doesn't rule out supporting restarting the runtime at some point and the shutdown code is routinely tested (tests/embedded/cmmain.c). I agree that it's not necessarily the case that #8920 should have required caml_memprof_shutdown to be implemented, but is there a particular reason to remove it today?

Essentially, this is dead code that cannot be tested. Given that it is particularly easy to forget to re-initialize one of these global variables, the value of this piece of code is nearly zero (if, in the future, we need it, then we'd better check that we did not forget anything!).

My understanding is that the author of the "unloadable runtime" proposal wanted to eventually have a restartable runtime, but the first iteration does not try to support it. (I had forgotten about the details when I made this comment earlier.)

There is a caml_shutdown function and it does have use cases even without restartability -- clean unloading of memory allocated by a runtime-as-dynamic-plugin. I'm not sure why we should remove caml_memprof_shutdown and not the rest of these functions. If I was a user with a need for caml_shutdown, I could test that it works properly by, say, using valgrind to check that shutdown correctly deallocated any heap space of the OCaml runtime. Doesn't the change you propose break this test / property?

This being said, this is your code, and we don't know how many users of caml_shutdown we have around. If you strongly feel that this function is a maintenance problem, it's probably okay to remove it.

Answering to myself: not having a memprof-specific function is in fact fine for mere unloadability: given that all memprof resources are allocated through caml_stat_alloc, it will be cleaned up automatically by the caml_stat_destroy_pool in caml_shutdown. Shutdown functions are important for pieces of the runtime that allocate not-pool-tracked resources.

With this point understood, I think that the PR is okay.

And BTW, I am not sure but: do you agree that this PR does not deserve a Changes entry?

I'm fine with not having a Changes entry. I suppose we would also cherry-pick in 4.11?

Properly speaking, this is not a bugfix. So there is no need backporting.

I would backport if this function was new in 4.11 (to ensure that no released version has the feature, instead of just one), but in fact I suspect we already had it in the not-user-exposed runtime part in 4.10, so I agree that there is not much point to backport.

Conflict fixed. Ready to merge.

Could we merge this, please?

Merged. (Don't you have the access rights to merge yourself?)