[kazinator]

It's a curious sentence and one of only two to mention timing, the other being the introduction's mention of the "unpredictable timing" of garbage collection.

Obviously it is true in a single threaded system. If the one and only thread executes a basic block of instructions, none of which call into memory management, or call any functions which might do that, then it holds that it's not interrupted by garbage collection.

If there are threads, and a stop-the-world discipline for GC, then obviously not.

Note that garbage collection itself can have a switch, not involving disabling interrupts. Of course, you wouldn't want to insert that around every block that doesn't need GC. I'm just mentioning that in order to note that we don't a heavy hammer like disabling interrupts in order to momentarily disable garbage collection. When GC is disabled, it is still possible to allocate objects, but no garbage collection passes are invoked to reclaim storage. This means that if the allocator has exhausted the available heaps, since it is not able to run a garbage collection pass, it has to ask the system for more memory for a new heap.

I've used a switch like this around calls to a Yacc-generated parser, due to the Yacc stack being invisible to the garbage collector; newly allocated objects could be prematurely reclaimed as they are being "laundered" through the Yacc stack before being nailed into the abstract syntax tree.

[moring]

> Obviously it is true in a single threaded system.

But only if you disable interrupts, right? Of course, if you are working that close to the hardware, it makes sense to include "no interrupts" in your definition of "single threaded".

> Note that garbage collection itself can have a switch, not involving disabling interrupts.

I don't understand this. If you get thrashed with interrupts then no switch will remove the overhead of the interrupt handler, so you'd need an upper bound on the time for that handler AND the frequency of hardware interrupts to achieve hard real-time.

[kazinator]

The only reason you'd need to disable interrupts to be sure that GC is not called over some block of code is if interrupt service routines are allowed to invoke GC.

For that to work, thread-like concurrency issues already have to be solved in the run-time.

Separately from that, we can have a system in which interrupts are allowed to call into the garbage collection module in order to allocate objects from an atomic free list, but a garbage collection pass is not allowed in interrupt context. (Allowing garbage collection passes, even if ephemeral, in interrupt context strikes as a bad idea because you generally want interrupt context to do as little work as possible.)

Now if we care about some block of instructions executing with absolute minimal delay then we do have to disable interrupts (at least local interrupts on the processor where that block is executed). We don't want the code to be interrupted to service any interrupts. No timer interrupts, no network interrupts, nothing. It is not related to GC.