4 ms·

> As of now, the only really-good GCs are found in the JVM This is quite a strong assertion. What other GCs have you evaluated and rejected as not-really-good

by mietek 13y ago

> As of now, the only really-good GCs are found in the JVM This is quite a strong assertion. What other GCs have you evaluated and rejected as not-really-good? Does this include GHC's parallel generational GC, or BEAM VM's per-process GC?

trailfox 13y ago
Perhaps he meant really good GCs in mainstream systems? It is a bit of an assertion on his part, but Java GCs are pretty advanced relative to most mainstream languages.
pron 13y ago
I know nothing of the GHC GC (though the JVM has had a parallel, generational GC for many years, and is probably considered the least advanced of the JVM GCs), but BEAM's GC, as you mentioned, is per-process, and thus does not help with shared data structures (which do exist in Erlang, namely ETS).
- mietek 13y ago
  It's not valid to say BEAM VM's per-process GC doesn't help with shared data structures, as there are no shared data structures in Erlang. ETS acts like shared memory, but is not, in fact, shared memory. ETS tables are kept in a separate memory region from process heaps, and aren't automatically garbage collected. They are destroyed when their parent process terminates, or manually. Per-process GC is a natural consequence of the way systems are built in Erlang, which often involves using hundreds of thousands of short-lived processes. This decreases a system's GC load, as entire process heaps can simply be destroyed when their process terminates, without needing to be traversed. There's also no need for a stop-the-world GC pause.
  - pron 13y ago
    Sure, but the fact that ETS tables exist shows that even Erlang recognizes the need in shared data. The fact that ETS tables aren't garbage collected is a limitation (and ETS tables have other limitations, too, like not supporting multi-object transactions). The Erlang GC cannot be compared with Java's GC. It is not "better" or "worse". Erlang's GC wasn't designed for better throughput but to ensure complete isolation. Erlang values isolation over everything else because it is at the core of Erlang's fault tolerance philosophy. In Java, a task could trigger a collection that could potentially block all other threads. This can't (I think) happen in Erlang. But the JVM's GC has many other advantages.
    - mietek 13y ago
      > multi-object concurrency I'm not familiar with this term, and it doesn't seem googleable. Can you give a definition? > The Erlang GC cannot be compared with Java's GC. And yet, by saying "the only really-good GCs are found in the JVM", you compare all GCs.
      - pron 13y ago
        multi-object concurrency Sorry. I meant multi-object transactions. Slip of the finger. And let me qualify: good GCs that are relevant to solving that problem GCs are essential for, namely concurrent data structures. Erlang doesn't have a GC that's relevant (I really like Erlang, BTW).
        mietek 13y ago
        Then surely you know support for transactions is built as a layer on top of ETS? I actually don't like Erlang as a whole, because it lacks a static type system, but that's besides the point. I reject characterising the BEAM VM's GC as not-really-good, especially in concurrency context. I believe the immutable, shared-nothing, message-passing model is a superior solution to the data problem than the threads-and-locks model. Actual memory sharing is an optimization which can be applied by the runtime system, as it's done for binaries in Erlang.
carterschonwald 13y ago
The ghc gc, and the ghc rts generally, are really great pieces of engineering. Very readable code too! And the ghc gc / rts are getting better every release. I'm hoping to spend some time late summer / early fall evaluating how to get better Numa support in. (And jvm notably lacks any Numa story as far as I can tell)
- pjmlp 13y ago
  At least Oracle and IBM VM do support NUMA. Surely there might be other vendors supporting as well. http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.java.doc.60_26%2Fvm626%2FJ9%2FGC%2Fmm_gc_balanced_numa.html http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?top... -
  - carterschonwald 13y ago
    Gc support is the important first step. But then the next step of work is scheduling work in a locality aware way. The libnuma lib in Linux and the portable hwloc lib that's part of the openmpi project are example substrates. Admittedly, for most applications this second step won't make a large difference, but in my application domain, numerical computing, better memory locality at any given granularity can yield an order of magnitude improvement. Locality aware scheduling in this context can actually yield a slightly super linear speed in the multicore / multi socket regime because of vagaries of a systems memory bus topology. Ill hopefully be in a better position to quantify this last remark more precisely middle to late summer, assuming Wellposed's numerical product launch results in signing some early customers in the next 2 months.
    - pjmlp 13y ago
      Thanks for the explanation. I never used NUMA systems.

by mietek 13y ago

trailfox 13y ago

Perhaps he meant really good GCs in mainstream systems? It is a bit of an assertion on his part, but Java GCs are pretty advanced relative to most mainstream languages.

pron 13y ago

I know nothing of the GHC GC (though the JVM has had a parallel, generational GC for many years, and is probably considered the least advanced of the JVM GCs), but BEAM's GC, as you mentioned, is per-process, and thus does not help with shared data structures (which do exist in Erlang, namely ETS).

mietek 13y ago
It's not valid to say BEAM VM's per-process GC doesn't help with shared data structures, as there are no shared data structures in Erlang. ETS acts like shared memory, but is not, in fact, shared memory. ETS tables are kept in a separate memory region from process heaps, and aren't automatically garbage collected. They are destroyed when their parent process terminates, or manually. Per-process GC is a natural consequence of the way systems are built in Erlang, which often involves using hundreds of thousands of short-lived processes. This decreases a system's GC load, as entire process heaps can simply be destroyed when their process terminates, without needing to be traversed. There's also no need for a stop-the-world GC pause.
- pron 13y ago
  Sure, but the fact that ETS tables exist shows that even Erlang recognizes the need in shared data. The fact that ETS tables aren't garbage collected is a limitation (and ETS tables have other limitations, too, like not supporting multi-object transactions). The Erlang GC cannot be compared with Java's GC. It is not "better" or "worse". Erlang's GC wasn't designed for better throughput but to ensure complete isolation. Erlang values isolation over everything else because it is at the core of Erlang's fault tolerance philosophy. In Java, a task could trigger a collection that could potentially block all other threads. This can't (I think) happen in Erlang. But the JVM's GC has many other advantages.
  - mietek 13y ago
    > multi-object concurrency I'm not familiar with this term, and it doesn't seem googleable. Can you give a definition? > The Erlang GC cannot be compared with Java's GC. And yet, by saying "the only really-good GCs are found in the JVM", you compare all GCs.
    - pron 13y ago
      multi-object concurrency Sorry. I meant multi-object transactions. Slip of the finger. And let me qualify: good GCs that are relevant to solving that problem GCs are essential for, namely concurrent data structures. Erlang doesn't have a GC that's relevant (I really like Erlang, BTW).
      - mietek 13y ago
        Then surely you know support for transactions is built as a layer on top of ETS? I actually don't like Erlang as a whole, because it lacks a static type system, but that's besides the point. I reject characterising the BEAM VM's GC as not-really-good, especially in concurrency context. I believe the immutable, shared-nothing, message-passing model is a superior solution to the data problem than the threads-and-locks model. Actual memory sharing is an optimization which can be applied by the runtime system, as it's done for binaries in Erlang.

carterschonwald 13y ago

The ghc gc, and the ghc rts generally, are really great pieces of engineering. Very readable code too! And the ghc gc / rts are getting better every release. I'm hoping to spend some time late summer / early fall evaluating how to get better Numa support in. (And jvm notably lacks any Numa story as far as I can tell)

pjmlp 13y ago
At least Oracle and IBM VM do support NUMA. Surely there might be other vendors supporting as well. http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.java.doc.60_26%2Fvm626%2FJ9%2FGC%2Fmm_gc_balanced_numa.html http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?top... -
- carterschonwald 13y ago
  Gc support is the important first step. But then the next step of work is scheduling work in a locality aware way. The libnuma lib in Linux and the portable hwloc lib that's part of the openmpi project are example substrates. Admittedly, for most applications this second step won't make a large difference, but in my application domain, numerical computing, better memory locality at any given granularity can yield an order of magnitude improvement. Locality aware scheduling in this context can actually yield a slightly super linear speed in the multicore / multi socket regime because of vagaries of a systems memory bus topology. Ill hopefully be in a better position to quantify this last remark more precisely middle to late summer, assuming Wellposed's numerical product launch results in signing some early customers in the next 2 months.
  - pjmlp 13y ago
    Thanks for the explanation. I never used NUMA systems.