Generally GC is not a good choice to get a soft real-time attribute. But Erlang is GC based language can be soft real-time.
Does it mean Erlang have almost no GC latency? How does it work?
-
2Even the hard real-time garbage collectors exists. E.g., lambda-the-ultimate.org/node/2393 – SK-logic Apr 24 '12 at 15:20
-
@SK-logic I agree that there're some RTGC implementations. Anyway I have a big question; How can you guarantee collection workload distribution where you cannot know the collection timing? – Eonil Dec 4 '14 at 16:36
-
you should not care about collection timing - the only requirement that it never ever blocks your RT processes. – SK-logic Dec 4 '14 at 17:33
-
@SK-logic My question comes from concern about memory pressure. If it guarantees fully distributed (over time) small collections, sometimes heavy collection workload will be deferred, and program may create more garbages while it has been deferred. If this continues, memory can be exhausted in short period. Naive GC solves this by performing eventual full GC, but it is impossible in RTGC. Then I have to tune garbage generation to fit to the GC distribution algorithm, but how can I guarantee (because it's RT) proper workload distribution without knowing GC timing...? – Eonil Dec 5 '14 at 3:10
-
1I mean that if there is a known constant throughput of the garbage collector, with a known time in between epochs, you can, potentially, statically prove that your allocation rate do not exceed this threshold. Not sure if anyone is doing this in practice. – SK-logic Dec 5 '14 at 15:54
Erlang processes don't share memory, each one has its own heap and they can be garbage-collected independently.
Many small heaps result in many small GC-pauses, rather than few big ones.
-
1Here's great write-up on Erlang's GC (which includes your point and makes a few others): prog21.dadgum.com/16.html – scvalex Aug 5 '12 at 1:27
