Hacker News Reader

Comment by charlieflowers | Hacker News Reader

Still, there are times when GC is fine for a particular application. In those cases, Nimrod is pretty fantastic, especially given its metaprogramming capabilities.

View on HN

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?

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?

They probably use the same heap underneath.

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

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.

Reply on news.ycombinator.com