3 ms·

So they had to work with a few algorithms and tweaks. I wonder if there would be value in exposing the GC (and alloc) iface so others can implement without reco

So they had to work with a few algorithms and tweaks. I wonder if there would be value in exposing the GC (and alloc) iface so others can implement without recompiling the language. I would love to toy with a pluggable GC. Last I looked at .Net's when it was open sourced, it was a gargantuan cpp file. I know LLVM has it somewhat pluggable. We can see a lot of Go GC's work at https://github.com/golang/go/blob/master/src/runtime/mgc.go https://github.com/golang/go/blob/master/src/runtime/mgc.go but at quick glance, I couldn't see how I could plug in an alternative impl. Surely they had to build an experimentation abstraction to test their ideas, right? Or are GC's just so specialized and use so much internal knowledge that extracting a common iface is unreasonable? Also, > The math is absolutely fascinating, ping me for the design docs Ping! Publish them please.

Scaevolus 8y ago
The design docs are linked right below :) Go 1.5 concurrent garbage collector pacing: https://golang.org/s/go15gcpacing https://golang.org/s/go15gcpacing Proposal: Separate soft and hard heap size goal: https://github.com/golang/proposal/blob/master/design/14951-soft-heap-limit.md https://github.com/golang/proposal/blob/master/design/14951-...
mike_hearn 8y ago
The latest versions of OpenJDK have a pluggable GC interface, at the source level at least - you can't literally drop a DLL into a directory and load it dynamically, but the source code is modularised quite well and there are several different GC engines available to be chosen at startup.
- kodablah 8y ago
  Good to know, I knew that I could choose different ones at runtime via java args, but unaware there was a runtime interface. I see cpp code at [0] and some adjacent impls. is there a single C-level h file or is it cpp only? Any hello-world trivial impl? 0 - http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/hotspot/share/gc/shared http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/h...
  - pjmlp 8y ago
    You are looking for "JEP 304: Garbage Collector Interface". http://openjdk.java.net/jeps/304 http://openjdk.java.net/jeps/304 Naturally this is OpenJDK specific, other JVMs might do it differently.
  - mike_hearn 8y ago
    The hello world collector is called Epsilon. Epsilon is the simplest possible collector: it never collects at all. The next one up in complexity is called the serial collector. It's a stop the world mark/sweep design straight out of the 1980s, but it can be quite effective for small programs like command line tools, simple GUI apps etc because there's no heap overhead and no runtime overhead when not collecting. After that you get into the more advanced algorithms. In order they'd be parallel, CMS, G1, Shenandoah/ZGC. The different engines can be found one level up, here: http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/hotspot/share/gc/ http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/h... The directory you were looking at is code shared between the collectors.
    - kodablah 8y ago
      Ah yes, I saw the adjacent impls, didn't check deeper to see Epsilon was exactly what I was looking for. Thanks. I see even the ifaces are GPL sadly as are the impls. I am not sure the classpath exception applies to the interfaces. And I fear even reading/learning from the impls lest I want to use my GPL-gained knowledge on a distributed, non-GPL project.
      - mike_hearn 8y ago
        GPL doesn't affect knowledge, only code. You can go work on proprietary software using things you learned by reading GPLd code, don't worry about that.

Scaevolus 8y ago

The design docs are linked right below :) Go 1.5 concurrent garbage collector pacing: https://golang.org/s/go15gcpacing https://golang.org/s/go15gcpacing Proposal: Separate soft and hard heap size goal: https://github.com/golang/proposal/blob/master/design/14951-soft-heap-limit.md https://github.com/golang/proposal/blob/master/design/14951-...

mike_hearn 8y ago

The latest versions of OpenJDK have a pluggable GC interface, at the source level at least - you can't literally drop a DLL into a directory and load it dynamically, but the source code is modularised quite well and there are several different GC engines available to be chosen at startup.

kodablah 8y ago
Good to know, I knew that I could choose different ones at runtime via java args, but unaware there was a runtime interface. I see cpp code at [0] and some adjacent impls. is there a single C-level h file or is it cpp only? Any hello-world trivial impl? 0 - http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/hotspot/share/gc/shared http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/h...
- pjmlp 8y ago
  You are looking for "JEP 304: Garbage Collector Interface". http://openjdk.java.net/jeps/304 http://openjdk.java.net/jeps/304 Naturally this is OpenJDK specific, other JVMs might do it differently.
- mike_hearn 8y ago
  The hello world collector is called Epsilon. Epsilon is the simplest possible collector: it never collects at all. The next one up in complexity is called the serial collector. It's a stop the world mark/sweep design straight out of the 1980s, but it can be quite effective for small programs like command line tools, simple GUI apps etc because there's no heap overhead and no runtime overhead when not collecting. After that you get into the more advanced algorithms. In order they'd be parallel, CMS, G1, Shenandoah/ZGC. The different engines can be found one level up, here: http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/hotspot/share/gc/ http://hg.openjdk.java.net/jdk/jdk11/file/a0de9a3a6766/src/h... The directory you were looking at is code shared between the collectors.
  - kodablah 8y ago
    Ah yes, I saw the adjacent impls, didn't check deeper to see Epsilon was exactly what I was looking for. Thanks. I see even the ifaces are GPL sadly as are the impls. I am not sure the classpath exception applies to the interfaces. And I fear even reading/learning from the impls lest I want to use my GPL-gained knowledge on a distributed, non-GPL project.
    - mike_hearn 8y ago
      GPL doesn't affect knowledge, only code. You can go work on proprietary software using things you learned by reading GPLd code, don't worry about that.