If I understand correctly, this test uses the "self monitoring" approach where an OCaml program listens to its own events. It is written as two nested loops that could be described as such:

for i = 1 to epochs do
  for a = 1 to majors_per_epoch do
    <allocate a lot>
    Gc.full_major ();
  done;
  <poll runtime events accumulated so far>;
done;

The intent of the test is that the <poll runtime events so far> logic is run often enough that we never miss events. But in that other PR you are increasing the amount of events emitted by the GC (I guess?), and in fact the inner loops now emits too many events.

For a user program, my recommendation to avoid event loss would be to poll more often. Accordingly, my proposal for this test would be to reduce the majors_per_epoch value (for example, from 100 to 10) instead of increasing the default event size. This is a simpler change than the one you propose, for the same effect.

Yes, but this goes to the design of this particular test. The purpose of this test is not documented, and is unclear from its version history. The test was clearly close to the limit of ring buffer sizes (in PR #12390 I add a small number of additional events which pushes it over the edge), but it was deliberately structured in this way (large loop count inside small loop count). Not knowing the reason for that original design choice, I decided that I shouldn't touch it, but instead make a trivial change to the ring buffer size, while at the same time improving variable names and adding comments so that the structure of the whole test is clearer.

This test now also tests that the ocamltest control comment at the head of the file can be used to correctly change OCAMLRUNPARAM, to grow the ring buffer size.

The test was clearly close to the limit of ring buffer sizes (in PR #12390 I add a small number of additional events which pushes it over the edge), but it was deliberately structured in this way (large loop count inside small loop count). Not knowing the reason for that original design choice, I decided that I shouldn't touch it, but instead make a trivial change to the ring buffer size

I don't understand. If we believe (I am not convinced) that the test is deliberately structured to test an almost-full-event-buffer scenario, then neither your change (making the buffer comfortably larger) nor my proposal (polling comfortably more often) are good ideas.

@sadiqj, as the original author of this test, could you maybe comment on what is a desirable way to make the test more robust to addition of new runtime events?

while at the same time improving variable names and adding comments so that the structure of the whole test is clearer.

great, thanks!

OK, I've halved the number of collections and taken the ocamlrunparam part out. How's that @gasche ?