I am a bit worried by the "currently only used for the hot paths of _ and _". What is it based on ? On your previous experiments ? Isn't it likely that the more "spacetime" is used on other software, the list of hot paths and functions that will need to be optimized will grow until almost all standard functions are in ? In that case, do we really want to put such specific code for each of them in the runtime and compiler ?

Firstly, this is only an optimisation.
Secondly, yes, this is based on evidence looking at the time spent in libunwind whilst running instrumented programs. I think the number of functions of this form that give significant pressure on libunwind is actually likely to remain small.

I'm confused, since these functions are not exposed in public headers, so they should never be called from C, right?

Did you look at the possibility to annotate external that we don't want them to call libunwind for performance. In similar way than noalloc but here it would be this_function_alloc_only_the_return_value? The upside is that we don't have to modify the runtime and it is easy for users to add that flag to there hot C functions.

In the OCaml Memory Profiler, we have such an annotation, to declare functions that only allocates their return value, which allows us to tag the allocated value in C with the type of the result.

@alainfrisch : Well, people do use things in private headers (and will be able to do so more easily if @lefessan 's change is accepted) and additionally, they could be called from elsewhere in the runtime (although they do not appear to be at the moment).

@bobot : No, and I would hope it is in general not necessary; we should not have user code blocking the operation of a profiler. The performance degradation is not that great overall for a profiler of this complexity, and there may be some ways we can mitigate against libunwind slowness in the future (e.g. by always using frame pointers and writing a custom unwinder based on those).

@alainfrisch I grepped through our tree at work for uses of those two C functions, and in fact the only use that I can find is a binding to [caml_make_vect], but it's from OCaml as an external. So one approach would be to simply add comments saying that these functions assume they are called from OCaml. Does that sound reasonable for now?

Well, people do use things in private headers (and will be able to do so more easily if @lefessan 's change is accepted) and additionally, they could be called from elsewhere in the runtime (although they do not appear to be at the moment).

They are not even in private headers, and currently not called from anywhere in the runtime.

simply add comments saying that these functions assume they are called from OCaml. Does that sound reasonable for now?

For me, yes.

the only use that I can find is a binding to [caml_make_vect], but it's from OCaml as an external

Meaning that the original proposal would break this code, which is an extra reason not to change anything.

Generally speaking, are there cases of primitives exposed to OCaml code which are also effectively called from C directly? This seems rather weak in general, since an exception raised by the primitive cannot be captured by a C caller (which means it has no way to release any resource it might have allocated).

@alainfrisch In which case, we can close this pull request, as the necessary change (just comments) will be in the main Spacetime pull request. Please close it once you've had the discussion on the point you've just raised.