Also, the GC can be controlled, so you can set exactly when it is allowed to run, something like this for a game:

  gcDisable()
  while true:
    gameLogic()
    renderFrame()
    gcStep(us = leftTime)
    sleep(restTime)

http://nimrod-lang.org/gc.html

Then what happens if the GC keeps taking longer than the allowed time? Will it then not keep allocating more and more memory that will never be freed?

Likely, yes. (Welcome to real-time programming; if you don't keep track of your time-budget, you're gonna have a bad day.)

I haven't looked at Nimrod's GC, but I believe it's indeed incremental; it won't take more time than you give it, but it will leave things uncollected if you don't give it [enough] time.

in a game, detect gc pressure and schedule some slo mo candy to use as gc cover.

I guess so. This is only viable if you have enough time for garbage collection.

Nimrod's pointers to garbage collected memory are separate from the pointers you can allocate yourself. So you could do manual memory management on the parts that really need it - say for a game in a tight loop - and leave the collector to worry about the smaller and less time-critical stuff.

Also the GC is only triggered on a memory allocation. It doesn't run in a background thread or anything like that. So if the GC fails, then the allocation of memory fails (as I understand it) which means your scenario would be caught early.

> Nimrod's pointers to garbage collected memory are separate from the pointers you can allocate yourself.

Does this mean that they use different heaps?

No, they are on the same heap since the GC isn't a moving collector.

They probably use the same heap underneath.