5 ms·

> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Unless you're doing weird things wit

by apta 7y ago

> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Unless you're doing weird things with class loaders, this is a non-issue. > Erlang on the other hand has a VM that makes GC much faster than in other languages What makes Erlang's VM make GC faster than other languages?

geocar 7y ago
That's a very loaded question. I don't think it's easy to point to one thing Erlang is doing and say that is why it's faster, partly because I think the way Erlang programmers are encouraged to write their programs also has an effect; The language itself may have a greater effect on its GC performance than the GC implementation itself. As an example: In Erlang, we have function calls like F(X) but we also have message sends like F!X. Message sends get one type of memory treatment, while function calls get another one. The lifetime of objects you send via messaging is going to be different, and yet Java only has function(method) calls, so there's no way to hint this to Java. Maybe this information can be recovered with static/dynamic analysis, but in Erlang we have syntax to tell the VM what's going to happen. If you want to learn more about Erlang's internals, I can recommend Joe's original paper on the subject: http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397570F246B379399EB5A3FDDFF2C5E?doi=10.1.1.42.7791 http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397... since it describes a lot of the design that went into Erlang early, and: http://www.it.uu.se/research/publications/lic/2005-001/ http://www.it.uu.se/research/publications/lic/2005-001/ which while long, quite in-depth describes many of the sub-optimisations that can be realised on top of it.
- apta 7y ago
  Thanks for the links. That being said, new developments in GCs on the JVM (like Shenandoah and ZGC) are yielding very impressive results. Things like < 1ms pause times for heaps in the TB range. No other free GC for any other language approaches this as far as I'm aware, including golang's which people claim is fast, but completely gets destroyed for even heaps in the GB range (I did some benchmarks).

by apta 7y ago

geocar 7y ago

That's a very loaded question. I don't think it's easy to point to one thing Erlang is doing and say that is why it's faster, partly because I think the way Erlang programmers are encouraged to write their programs also has an effect; The language itself may have a greater effect on its GC performance than the GC implementation itself. As an example: In Erlang, we have function calls like F(X) but we also have message sends like F!X. Message sends get one type of memory treatment, while function calls get another one. The lifetime of objects you send via messaging is going to be different, and yet Java only has function(method) calls, so there's no way to hint this to Java. Maybe this information can be recovered with static/dynamic analysis, but in Erlang we have syntax to tell the VM what's going to happen. If you want to learn more about Erlang's internals, I can recommend Joe's original paper on the subject: http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397570F246B379399EB5A3FDDFF2C5E?doi=10.1.1.42.7791 http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397... since it describes a lot of the design that went into Erlang early, and: http://www.it.uu.se/research/publications/lic/2005-001/ http://www.it.uu.se/research/publications/lic/2005-001/ which while long, quite in-depth describes many of the sub-optimisations that can be realised on top of it.

apta 7y ago
Thanks for the links. That being said, new developments in GCs on the JVM (like Shenandoah and ZGC) are yielding very impressive results. Things like < 1ms pause times for heaps in the TB range. No other free GC for any other language approaches this as far as I'm aware, including golang's which people claim is fast, but completely gets destroyed for even heaps in the GB range (I did some benchmarks).