5 ms·

Gossamer has a cycle collector and eager reference counting. Good luck dropping the last reference to a 10,000-node graph, especially if cyclic. That means it d

Gossamer has a cycle collector and eager reference counting. Good luck dropping the last reference to a 10,000-node graph, especially if cyclic. That means it doesn't have "pause free" memory. If you want pause freedom, go use ZGC or another modern GC on a modern VM. I just can't take seriously this spate of languages that ignore the past 30 years of research into automatic memory management. We have multiple open-source pauseless miracles GCs right there before our eyes, yet it's the trendy thing in language design to foist memory management on users. You don't even have to use a big VM if you want good GC. Go use MPS. Lots of options out there, even if you want to implement your own VM.

platinumrad 4mo ago
> We have multiple open-source pauseleses miracles right there before our eyes Is this meaningfully true in a practical sense? I've been writing code with soft real-time requirements and I don't think your notion of "pauseless" suffices. And if these miracles are open-source and right before our eyes, why do languages like Crystal and D still use Boehm?
- quotemstr 4mo ago
  The charitable explanation is the authors lack the time to rebase onto something more modern.
  - platinumrad 4mo ago
    You seem to have a very low opinion of other people. If these miraculous collectors are so generally applicable, why are very smart people putting effort into things like Perseus?
    - quotemstr 4mo ago
      Smart, honest people can have sincere and earnest disagreements. I believe the manual-memory-management people are mistaken. That's not to say they're stupid: it means I believe they're going down the wrong path, as smart people have done since time immemorial. I wish them all the best. That said, I must wonder what other innovations they reject if they insist that GC is unacceptable.
      - lstodd 4mo ago
        We insist that GC is unacceptable only because we insist that uncontrollable latency is unacceptable.
        LoganDark 4mo ago
        The entire concept of a pauseless GC is that you have no uncontrollable latency. The GC can run on a background thread with zero stop-the-world. Of course, this assumes you're in a preemptive environment with access to other threads, etc.
        yunuskusak 4mo ago
        @LoganDark You're right, as long as there is an object graph to scan, 'uncontrollable' latency is an inherent trade-off in GC-based systems. I’ve taken a different route with a C++20 execution engine that eliminates the object graph scan entirely by using pre-allocated, static memory pools and lock-free SPSC structures. It's essentially moving from 'managing GC pauses' to 'deterministic, zero-allocation execution'. Have you ever benchmarked your systems against a lock-free architecture that bypasses the allocator on the hot path?
        LoganDark 4mo ago
        The lock-free architecture that bypasses the allocator on the hot path is called `alloca`. Many mainstream compilers, and nearly every language that is not C, seemingly haven't properly supported it for years.
        lstodd 4mo ago
        Please don't twist. alloca is in fact a limited arena/pool allocator and as such for some small sizes it is latency-free. It is also there in C. It does not have anything to do with GCs. You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling. This is false. One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false. There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
- gomoboo 4mo ago
  D uses a homegrown GC not Boehm: - https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html - https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/ https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
- nu11ptr 4mo ago
  > why do languages like Crystal and D still use Boehm? Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system (it was designed for use in C/C++). I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (free list allocator), poor cache locality, and not precise (so you can expect memory leaks). If you are going to do a GC language you want: 1) precise 2) bump allocator 3) compacting collector 4) generations. Essentially you want to allocate fast, only touch live objects (most objects die young), compact them for locality, and only process objects each cycle of similar age. There is a huge amount of engineering that goes into a state of the art collector, but those are the basics.
  - mappu 4mo ago
    This is all true but is a somewhat Java-flavoured perspective i.e. generations ties you into a moving collector, which ties you into barriers and complicates FFI, which is not always the right tradeoff. A non-fragmenting allocator goes a long way to alleviating the need for compactions too.
    - nu11ptr 4mo ago
      Not necessarily Java-flavored, but internally vs externally focused, yes. More difficult FFI assuming that is the exception not the rule, and that the language itself takes precedence. Write barriers are also not a given if using segmented heaps. Many ways to do this and no single right way. Memory allocation scheme isn't something that is just bolted on, but needs to be aligned to the rest of the language. For example, Java needs such fast allocations and good GC because it does almost no inline allocation whatsoever, so without the best GC on the planet, it would be a lot slower than it is. Contrast this with Go, which has a solid amount of inline allocations, and hence, can get by with a much slower allocator (~3-4x slower by my measurements) and a more basic mark-sweep allocator since the memory pressure is solidly less.
iyn 4mo ago
> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?
- quotemstr 4mo ago
  ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is also very good: https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc. V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.) I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.
  - platinumrad 4mo ago
    If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.
    - phplovesong 4mo ago
      You just described http://www.lisette.run http://www.lisette.run
    - mappu 4mo ago
      Cgo is cheap these days, don't worry about it. It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
smj-edison 4mo ago
The one plus I'll give reference counting is it still takes the cake for interoperability with C. Which is only important if you need good interoperability, but when you do, tracing GCs don't play nice.

platinumrad 4mo ago

> We have multiple open-source pauseleses miracles right there before our eyes Is this meaningfully true in a practical sense? I've been writing code with soft real-time requirements and I don't think your notion of "pauseless" suffices. And if these miracles are open-source and right before our eyes, why do languages like Crystal and D still use Boehm?

quotemstr 4mo ago
The charitable explanation is the authors lack the time to rebase onto something more modern.
- platinumrad 4mo ago
  You seem to have a very low opinion of other people. If these miraculous collectors are so generally applicable, why are very smart people putting effort into things like Perseus?
  - quotemstr 4mo ago
    Smart, honest people can have sincere and earnest disagreements. I believe the manual-memory-management people are mistaken. That's not to say they're stupid: it means I believe they're going down the wrong path, as smart people have done since time immemorial. I wish them all the best. That said, I must wonder what other innovations they reject if they insist that GC is unacceptable.
    - lstodd 4mo ago
      We insist that GC is unacceptable only because we insist that uncontrollable latency is unacceptable.
      - LoganDark 4mo ago
        The entire concept of a pauseless GC is that you have no uncontrollable latency. The GC can run on a background thread with zero stop-the-world. Of course, this assumes you're in a preemptive environment with access to other threads, etc.
        yunuskusak 4mo ago
        @LoganDark You're right, as long as there is an object graph to scan, 'uncontrollable' latency is an inherent trade-off in GC-based systems. I’ve taken a different route with a C++20 execution engine that eliminates the object graph scan entirely by using pre-allocated, static memory pools and lock-free SPSC structures. It's essentially moving from 'managing GC pauses' to 'deterministic, zero-allocation execution'. Have you ever benchmarked your systems against a lock-free architecture that bypasses the allocator on the hot path?
        LoganDark 4mo ago
        The lock-free architecture that bypasses the allocator on the hot path is called `alloca`. Many mainstream compilers, and nearly every language that is not C, seemingly haven't properly supported it for years.
        lstodd 4mo ago
        Please don't twist. alloca is in fact a limited arena/pool allocator and as such for some small sizes it is latency-free. It is also there in C. It does not have anything to do with GCs. You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling. This is false. One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false. There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
gomoboo 4mo ago
D uses a homegrown GC not Boehm: - https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html - https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/ https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
nu11ptr 4mo ago
> why do languages like Crystal and D still use Boehm? Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system (it was designed for use in C/C++). I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (free list allocator), poor cache locality, and not precise (so you can expect memory leaks). If you are going to do a GC language you want: 1) precise 2) bump allocator 3) compacting collector 4) generations. Essentially you want to allocate fast, only touch live objects (most objects die young), compact them for locality, and only process objects each cycle of similar age. There is a huge amount of engineering that goes into a state of the art collector, but those are the basics.
- mappu 4mo ago
  This is all true but is a somewhat Java-flavoured perspective i.e. generations ties you into a moving collector, which ties you into barriers and complicates FFI, which is not always the right tradeoff. A non-fragmenting allocator goes a long way to alleviating the need for compactions too.
  - nu11ptr 4mo ago
    Not necessarily Java-flavored, but internally vs externally focused, yes. More difficult FFI assuming that is the exception not the rule, and that the language itself takes precedence. Write barriers are also not a given if using segmented heaps. Many ways to do this and no single right way. Memory allocation scheme isn't something that is just bolted on, but needs to be aligned to the rest of the language. For example, Java needs such fast allocations and good GC because it does almost no inline allocation whatsoever, so without the best GC on the planet, it would be a lot slower than it is. Contrast this with Go, which has a solid amount of inline allocations, and hence, can get by with a much slower allocator (~3-4x slower by my measurements) and a more basic mark-sweep allocator since the memory pressure is solidly less.

iyn 4mo ago

> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?

quotemstr 4mo ago
ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is also very good: https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc. V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.) I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.
- platinumrad 4mo ago
  If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.
  - phplovesong 4mo ago
    You just described http://www.lisette.run http://www.lisette.run
  - mappu 4mo ago
    Cgo is cheap these days, don't worry about it. It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.

smj-edison 4mo ago

The one plus I'll give reference counting is it still takes the cake for interoperability with C. Which is only important if you need good interoperability, but when you do, tracing GCs don't play nice.