Hacker News Reader

Comment by dleslie | Hacker News Reader

Woah, I like the solid memory guarantees. Could be useful for embedded projects.

Seems to use quite a bit of stack for an embedded usage. An interesting thing to note: microcontrollers are typically memory-bound when using common algorithms - while they are maybe 100x slower than a desktop computer they have say 1000000x less RAM. So, for example, a GC cycle would be often in the range of 1ms.

Wouldn’t a GC cycle be short if the microcontroller had less RAM? (as a genuine question)

1ms is pretty short. GC cycles on desktops and servers can take hundreds of ms.

I've seen pathological examples where a gc takes 30 seconds

GC is the bubblesort of our era. I mean it seems to be a very inefficient way to solve a problem.

I hope computer scientists will come up with something better than GC.

Isn't that what Rust is all about?

Rust is for memory safety. GC software is a way to achieve some form of memory safety while also being much simpler and faster to write compared to Rust.

Honestly I'm not sure. Modern GCs are pretty good, and manual memory management isn't a free lunch either. One major advantage of a GC is it can batch all the `free`s together which is a lot more efficient than the manual approach where you free objects individually in a pseudo-random order.

But only with very very bad GC's. Like stop the world mark&sweep. Nobody should ever use that, but they are quite common still.

ZGC (JVM) now has guaranteed maximum pause times of 500 microseconds, with average pause times of just 50 microseconds: https://malloc.se/blog/zgc-jdk16

Pause time is not the same as cycle time, but it’s what’s important for reactivity.

Sure, but deferring collection requires increasing memory use. Since the OP was discussing microcontrollers, that's generally not desirable because memory is in short supply. A 1ms GC cycle is totally tolerable for most microcontroller applications though.

I was responding to your statement regarding “on desktops and servers”, which I believe doesn’t quite represent the state of the art anymore. I certainly agree that 1 ms is already pretty short.

Well yes. The less heap to scan the faster it is. I was just referreing to the unusual ratio between speed and RAM.

The bigger problem with GC and standard allocators on embedded system is heap fragmentation, in my experience.

Couldn't agree more! One way I was fighting it (in Static Typescript [0]) is by increasing frequency of scans and allocating as close as possible to one side of the heap. Next time I think I'll just try to compact the heap.

[0] https://www.microsoft.com/en-us/research/uploads/prod/2019/0...

Oof, heavy stack usage is ungood. But that's probably correctable.

FWIW, I'm thinking of devices that don't have an MMU - like the Sega 32X. It's a hobby of mine. Having any GC time at all is too much suffering, even 1ms.

Reply on news.ycombinator.com