Gabriel Scherer

> Or maybe `2 x sysconf(_SC_NPROCESSORS_CONF)` on Unix-like platforms. But that's probably too much bikeshed already. One issue with this is that it would break on the current default for...

@kayceesrk would it also be possible to have a Sandmark run for this PR? I don't expect any performance difference because I don't think we rely intensively on domain-indexed arrays...

@gadmm makes the point that this introduces conflicts with other in-flight PRs ( #12410, #12964, #13026 ). I still believe that "merge whichever is ready first" is a good principle,...

My impression is that @xavierleroy would be the right person to look at this.

There are three occurrences of `__tsan_func_exit(0)` in *comments* in .S files (risc, s390, arm64), I guess the `0` should be dropped.

There has been discussions in #13981 about protecting every call to the TSan runtime by a runtime check. A reasonable way to do this would be to first wrap every...

The current review state of this PR, according to my understanding, is as follows: 1. I'm happy with the general direction of having `caml_tsan_*` functions to centralize calls to the...

Regarding speed, I think we should evaluate it in the context of the current slowdown that we already have with TSan implementation. If say programs run 1.6x slower instead of...

This suggests a 2% slowdown, which is fine. Two remarks: 1. It would be better to evaluate the performance of `ocamlopt.opt` rather than `ocamlrun ocamlopt`: the bytecode version is slower...

Thanks for the detective chase. I think that we have two choices: 1. try to adapt runtime-events to have a 32bit version manipulating 32bit words rather than 64bit words (so:...