Should out-of-memory ever be caught in libraries/framework?

Ecosystem
21

It is not a real limitation that it requires (sys)threads. This is only meant to simplify the packaging, and I’d like to lift this limitation at some point. I could benefit from some helping hand there, from someone knowledgeable about dune/opam.

Since you mention lwt, this brings us back to @raphael-proust’s original question. Lwt seems a bigger obstacle for memprof-limits. I was always worried that adapting it would be more difficult, but I just figured that polling for interrupts at every monadic bind would be enough and quite simple to implement. If lwt devs or other contributors are interested in discussing this issue then I think we should be able to make progress.

22

Did you look if perhaps you could simply “let it crash” to C and restart the runtime system.

That is you write a C program that uses OCaml as a library. Your main program initializes the runtime system and runs it, if there’s a toplevel unexpected exception or if the Gc crashes, I think the function caml_fatal_error_hook should eventually be called. Here you can clean up and unload the runtime system and start it again without exiting the C program itself.

This would also make it reliable if the Gc gets out of memory, but I’m not sure if the goal articulated in this message was eventually achieved (but at least @jhjourdan got rid of the “OCaml library” exiting under your feet); especially many things happened to the runtime system since then.

23

The simplest the solution the better IMO, but it might not work because one cannot restart the runtime after shutting it down I think.

24

The docs are not clear to me. caml_shutdown came with @murmour’s PR here where the use case was repeateadly loading/unloading a shared library that had the ocaml program + runtime system. Now the docs I linked to say:

Once a runtime is unloaded, it cannot be started up again without reloading the shared library and reinitializing its static data. Therefore, at the moment, the facility is only useful for building reloadable shared libraries.

But it’s not exactly clear to me what this means if you statically link the OCaml library in an executable.

25

Indeed, this might refer to different situations. If you don’t reinitialize static data (e.g. by unloading/reloading the runtime with the dynamic linker), you must run into this check: https://github.com/ocaml/ocaml/blob/fcad2864/runtime/startup_aux.c#L135-L137.

26

So perhaps tuck a copy of your .data section with a custom linker script at a known address or by copying it at startup somewhere and rewrite the .data section from the copy before restarting the runtime system. (You’d have to be careful with the state of possibly linked in C libraries though)

27

If you want to use the caml_shutdown technique, you should be able to use my code at Register and deregister OCaml 4.14 runtime · GitHub after the bug in callbacks that run after caml_startup crash on stack overflow instead of raising Stack_overflow · Issue #11486 · ocaml/ocaml · GitHub is fixed. It seems like a very small change so if interested you might want to contribute a PR.

Similar use case: To manage a phone’s RAM when it starts to get full, Android asks service threads of apps that are not in the UI foreground to stop. OCaml is one of those service threads. If it can’t reduce the RAM requirements, then Android resorts to forcibly killing processes which sucks because you lose an app’s UI state. iOS has a similar mechanism which uses memory warnings.

28

I concur, since most of the global state was moved to the domain state in OCaml 4.10, it should be much easier now to make the runtime restartable.

I’d be interested in integrating OS memory pressure information with memprof-limits, so if one of you is interested too and could contribute for a specific platform, please get in touch.