5 ms·

Has anyone ever tried to port OpenJDK's fancy garbage collectors other runtimes? I guess often GCs are quite intimately tied to other details of the runtime and

Has anyone ever tried to port OpenJDK's fancy garbage collectors other runtimes? I guess often GCs are quite intimately tied to other details of the runtime and specialized to code patterns and use cases of particular languages, but still, would be interesting to hear about attempts.

titzer 4y ago
AFAIK, no. The opposite is true with MMtk (https://www.mmtk.io https://www.mmtk.io), which is a toolkit with many GC algorithms implemented that has been plugged into other runtimes, including, as it happens, OpenJDK.
mike_hearn 4y ago
That would be difficult. The GCs share a lot of code, and have a lot of code to deal with Java specific things like class unloading and soft/weak/phantom references. It's easier to run other languages on top of the JVM runtime, which is what projects like Truffle and JRuby do.
throwaway894345 4y ago
> I guess often GCs are quite intimately tied to other details of the runtime and specialized to code patterns and use cases of particular languages This is why I don't understand the WASM GC proposal, which I understand to be an attempt to make a GC that works for all languages. Can you really write a GC that performantly supports both Java and Go given the different tradeoffs/approaches each makes with respect to memory management, layout semantics, etc?
- fulafel 4y ago
  I agree somewhat. But still JVM GC works ok for several other languages (Clojure, JRuby, Scala, Kotlin etc).
  - throwaway894345 4y ago
    Sure, but all of those languages "look like Java" from a memory management perspective. Namely, programs written in those languages idiomatically assume that allocations are dirt cheap (bump allocator) and thus they allocate a lot of garbage. A language like Go tends to assume allocations are more expensive (tradeoff for a simple/non-moving, low latency GC) and consequently makes fewer, larger allocations. It's not obvious to me that a single GC can support both extremes performantly.
- entropicdrifter 4y ago
  >Can you really write a GC that performantly supports both Java and Go given the different tradeoffs/approaches each makes with respect to memory management, layout semantics, etc? I mean, the Graal JVM GC supports a ton of languages, especially if you include their LLVM support. Many of them are quite high performance. Truffle Ruby I believe is still (one of if not) the fastest Ruby implementation(s).
  - throwaway894345 4y ago
    Sure, but are the languages that Graal supports diverse from the perspective of the assumptions they make? E.g., it's not surprising to me that any JVM GC would work for Java, Ruby, Python, etc since all of these languages idiomatically allocate lots of garbage like allocations are cheap (they all "look like Java" from a memory management perspective). On the other hand, Go assumes allocations are expensive and it tends to make fewer, larger allocations (the tradeoff is that it can have a relatively simple, low latency GC). It's not clear to me that a single general purpose GC (i.e., it's performant for all cases, not just the things-that-look-like-Java case) can exist, but I'm also not a GC expert.
    - mike_hearn 4y ago
      Go doesn't differ that much from other GC languages. GC cost/complexity doesn't really change much with average allocation size. Go putting less load on the GC just means the JVM GCs would be playing on 'easy mode'.
      - fweimer 4y ago
        Go has interior pointers. All byte arrays support word-sized pointers to any of their array elements. I think that's somewhat unusual for a language implementation with a precise garbage collector. Usually, pointers always point to the start of the object they reference, and not at some arbitrary offset somewhere inside the object.
        NobleExpress 4y ago
- fweimer 4y ago
  If machine code is generated on (or close to) deployment, the implementation can choose a suitable collector. Hopefully, the proposed protocol will not require that implementations somehow optimize away interior object pointers for languages like Java that do not really need them, but make that obvious directly from the opcodes being used (or some other easily observed property). Likewise for the requirement to support pointer tagging for fixnums. Then the implementation can choose the appropriate collector based on what is being compiled (and the most general one for inter-language unification). Keep in mind that typical builds of Hotspot support four or five garbage collectors, and most of them with two different pointer sizes. The required read and write barriers differ widely between collectors and in some cases even collector modes. I'm not saying that it's going to be easy (an incredible amount of effort went into Hotspot over the years). But it's definitely possible to support wildly different GC strategies efficiently with sufficiently late code generation.
- vbezhenar 4y ago
  If you need ultimate performance, you need native implementation, end of story. Webassembly, as I see it, is about creating VM which provides acceptable performance with ultimate sandboxing. It's a replacement for JavaScript transpilation, not for JVM. Of course it's tempting to do it all without sacrificing anything, but I guess you can't have a cake and eat it too.
  - pjmlp 4y ago
    Except for VC sponsored startups trying the 2nd. coming of application servers.
- FullyFunctional 4y ago
  Certainly not for lazy FP language like Haskell. Its GC is highly specialized for that, including performing some non-allocating reductions during GC, having special support for detecting looping computation (holes), etc.
  - NobleExpress 4y ago
    [dead]
lemming 4y ago
I've wondered how feasible this would be. In general, I think the other commenters are correct that GCs tend to be intimately tied to the runtimes. But the JVM now has an interface for garbage collection (https://openjdk.org/jeps/304 https://openjdk.org/jeps/304), which might make the GCs easier to extract and use in other projects. I'm not aware of anyone trying though.
NobleExpress 4y ago
Someone ported the G1 collector to JikesRVM [1], a research Java VM. It's not a production case-study of course, but interesting nonetheless. [1]: https://users.cecs.anu.edu.au/~steveb/pubs/papers/g1-vee-2020.pdf https://users.cecs.anu.edu.au/~steveb/pubs/papers/g1-vee-202...
pjmlp 4y ago
Other runtimes also have fancy GC, JIT and AOTs of their own. That is the cool thing about having multiple implementations.

titzer 4y ago

AFAIK, no. The opposite is true with MMtk (https://www.mmtk.io https://www.mmtk.io), which is a toolkit with many GC algorithms implemented that has been plugged into other runtimes, including, as it happens, OpenJDK.

mike_hearn 4y ago

That would be difficult. The GCs share a lot of code, and have a lot of code to deal with Java specific things like class unloading and soft/weak/phantom references. It's easier to run other languages on top of the JVM runtime, which is what projects like Truffle and JRuby do.

throwaway894345 4y ago

> I guess often GCs are quite intimately tied to other details of the runtime and specialized to code patterns and use cases of particular languages This is why I don't understand the WASM GC proposal, which I understand to be an attempt to make a GC that works for all languages. Can you really write a GC that performantly supports both Java and Go given the different tradeoffs/approaches each makes with respect to memory management, layout semantics, etc?

fulafel 4y ago
I agree somewhat. But still JVM GC works ok for several other languages (Clojure, JRuby, Scala, Kotlin etc).
- throwaway894345 4y ago
  Sure, but all of those languages "look like Java" from a memory management perspective. Namely, programs written in those languages idiomatically assume that allocations are dirt cheap (bump allocator) and thus they allocate a lot of garbage. A language like Go tends to assume allocations are more expensive (tradeoff for a simple/non-moving, low latency GC) and consequently makes fewer, larger allocations. It's not obvious to me that a single GC can support both extremes performantly.
entropicdrifter 4y ago
>Can you really write a GC that performantly supports both Java and Go given the different tradeoffs/approaches each makes with respect to memory management, layout semantics, etc? I mean, the Graal JVM GC supports a ton of languages, especially if you include their LLVM support. Many of them are quite high performance. Truffle Ruby I believe is still (one of if not) the fastest Ruby implementation(s).
- throwaway894345 4y ago
  Sure, but are the languages that Graal supports diverse from the perspective of the assumptions they make? E.g., it's not surprising to me that any JVM GC would work for Java, Ruby, Python, etc since all of these languages idiomatically allocate lots of garbage like allocations are cheap (they all "look like Java" from a memory management perspective). On the other hand, Go assumes allocations are expensive and it tends to make fewer, larger allocations (the tradeoff is that it can have a relatively simple, low latency GC). It's not clear to me that a single general purpose GC (i.e., it's performant for all cases, not just the things-that-look-like-Java case) can exist, but I'm also not a GC expert.
  - mike_hearn 4y ago
    Go doesn't differ that much from other GC languages. GC cost/complexity doesn't really change much with average allocation size. Go putting less load on the GC just means the JVM GCs would be playing on 'easy mode'.
    - fweimer 4y ago
      Go has interior pointers. All byte arrays support word-sized pointers to any of their array elements. I think that's somewhat unusual for a language implementation with a precise garbage collector. Usually, pointers always point to the start of the object they reference, and not at some arbitrary offset somewhere inside the object.
      - NobleExpress 4y ago
fweimer 4y ago
If machine code is generated on (or close to) deployment, the implementation can choose a suitable collector. Hopefully, the proposed protocol will not require that implementations somehow optimize away interior object pointers for languages like Java that do not really need them, but make that obvious directly from the opcodes being used (or some other easily observed property). Likewise for the requirement to support pointer tagging for fixnums. Then the implementation can choose the appropriate collector based on what is being compiled (and the most general one for inter-language unification). Keep in mind that typical builds of Hotspot support four or five garbage collectors, and most of them with two different pointer sizes. The required read and write barriers differ widely between collectors and in some cases even collector modes. I'm not saying that it's going to be easy (an incredible amount of effort went into Hotspot over the years). But it's definitely possible to support wildly different GC strategies efficiently with sufficiently late code generation.
vbezhenar 4y ago
If you need ultimate performance, you need native implementation, end of story. Webassembly, as I see it, is about creating VM which provides acceptable performance with ultimate sandboxing. It's a replacement for JavaScript transpilation, not for JVM. Of course it's tempting to do it all without sacrificing anything, but I guess you can't have a cake and eat it too.
- pjmlp 4y ago
  Except for VC sponsored startups trying the 2nd. coming of application servers.
FullyFunctional 4y ago
Certainly not for lazy FP language like Haskell. Its GC is highly specialized for that, including performing some non-allocating reductions during GC, having special support for detecting looping computation (holes), etc.
- NobleExpress 4y ago
  [dead]

lemming 4y ago

I've wondered how feasible this would be. In general, I think the other commenters are correct that GCs tend to be intimately tied to the runtimes. But the JVM now has an interface for garbage collection (https://openjdk.org/jeps/304 https://openjdk.org/jeps/304), which might make the GCs easier to extract and use in other projects. I'm not aware of anyone trying though.

NobleExpress 4y ago

Someone ported the G1 collector to JikesRVM [1], a research Java VM. It's not a production case-study of course, but interesting nonetheless. [1]: https://users.cecs.anu.edu.au/~steveb/pubs/papers/g1-vee-2020.pdf https://users.cecs.anu.edu.au/~steveb/pubs/papers/g1-vee-202...

pjmlp 4y ago

Other runtimes also have fancy GC, JIT and AOTs of their own. That is the cool thing about having multiple implementations.