Mixed memory model for Crystal

Crystal Contrib
1

Hey guys and gals!

What do you think about the mixed memory model, where the compiler decides for itself what allocation to use for the variable: stack, slab ARC, atomic ARC, or, as a last resort, it will be GC?

Will it strike your interest in the Crystal even more?
May this feature give Crystal a competitive advantage, and will Go and Rust be sunset?

Really love to hear your suggestions and cool ideas!

All the Best!
Sergey

5 Likes
2

Cool idea in theory. But the magic of Crystal is I don’t think about memory - I just write code. If the compiler starts picking between 4 different strategies, now I’m wondering “which one did it pick?” when debugging perf issues. Adds mental overhead even if it’s automatic.

Will it strike your interest in the Crystal even more?

For me personally, things like better tooling, faster compile times, and a growing library ecosystem would move the needle more. The current memory model hasn’t been a blocker in my experience.

On competitive advantage over Go/Rust:

Go’s advantage isn’t memory model - it’s simplicity, goroutines, and Google backing. Rust’s advantage is zero-cost abstractions with compile-time guarantees. A smarter GC doesn’t compete with either of those value props.

On sunsetting Go and Rust:

Not gonna happen. They have massive ecosystems, corporate backing, and solve different problems. Crystal’s path forward is being the best Crystal, not trying to out-Go Go or out-Rust Rust.

On escape analysis / stack allocation:

This part I’d actually love. If the compiler can prove something doesn’t escape, stack allocate it. Free perf, no mental model change. Swift does this well.

6 Likes
3

I am actually testing and polishing the last bugs, so I will see how it can improve Crystal’s performance and how easy it will be for developers.

2 Likes
4

I heard Nim can change its memory management model with command-line options. You can pick reference counting or GC.
Nim people seem to think, “We won’t lose to Crystal on memory efficiency.”

5

They can select only one or the other, but not all five different memory models at the same time, depending on what is best for a specific variable.

3 Likes
6

I’d say RFC 0004: HEAP escape analysis for starters?

Now, about Automatic Reference Counting (ARC) you’re making me curious :eyes:

But I’d see ARC as an alternative to the GC (or something like Immix RC), not happening as a parallel HEAP to the GC HEAP. For example the GC would still have to scan & mark the ARC HEAP and do pauses for collections :confused: Saw your previous message :see_no_evil_monkey:

7

Note: ARC still has some runtime cost over the GC, though there has been lots of papers to optimize the costs (i.e. avoid counting), and memory management like Immix RC may help go further.

1 Like
8

I implemented it via Escape/Taint analysis.
You can look at the codegen branch in my repo: GitHub - skuznetsov/crystal_lsp: Crystal Lang LSP server with ground-built Crystal Lang parser/type inferrer, that is LSP friendly and allows to reload individual files without whole tree reparsing.

Here is the codegen architecture doc, which is a little bit dated, but shows all the ideas: crystal_lsp/docs/codegen_architecture.md at codegen · skuznetsov/crystal_lsp · GitHub

2 Likes