[octachron]

Of course not.

Honestly, I am not sure what was the initial sentence before being distorted by the editor. The next sentence makes me think that the interviewee might have been discoursing about all the tricks that Janestreet uses to reduce allocation to a minimum but it is hard to tell from the final text.

[cempaka]

From the transcript of the source podcast on Jane Street's website:

> A good example is we’re a garbage collected language, our garbage collector inspects values at runtime. Therefore, uninitialized data can be really problematic. And so we have to do stupid things in my brain like, oh, it’s really important to null out the pointers in this array and not just leave them behind or they’ll leak, or you can’t just have an uninitialized array that I promise I’ll get too soon. Because what happens if you GC in that range? And I do actually think this is meaningfully costly in some scenarios, but I’m willing to put up with it.

I'm still a little unsure exactly what this means though.

The whole podcast is worth a listen, I had never heard about the feature on Intel CPUs which allows you to replay the last 2 milliseconds of instructions on the chip.

[octachron]

Ok, now I understand: this part is a description of how optimizing C bindings using the OCaml FFI often requires to play around the GC:

With OCaml uniform representation of data, the GC will follow all data that looks like a pointer in its reachable set of values. Which is the right thing to do for valid OCaml values, for which anything that looks like a pointer (outside of strings or numerical arrays) is a pointer to a valid OCaml value.

However if you are building OCaml values in the C FFI, and that this in-construction value is somehow reachable by the GC, you have to make sure that there is no pointer in the uninitialized part of the data. Or alternatively you need to make sure that the runtime will not enter a GC phase while you are building those values.