Her idea was that a GC in Rust can use a futures-like API, and the space between polls is where gc pauses can happen. It didn't use async yet but it could do something like that in the future.
see github.com/kyren/luster/b
(the overall gc design here is very cool, check it out)
Conversation
I pointed out that this is actually quite similar to what Go does: Go generates automatic GC interruption points, and the same mechanism powers async I/O scheduling
4
1
17
Is this because you can kind of think of GC - or any dynamic allocation - as an effect? I'm imagining a GC-less language with algebraic effects and handlers might form another alternate foundation here (see how Multicore OCaml uses effect handlers for async scheduling).
1
1
Yes, looking at GC-ish functions as having a different "color" helps.
But effects are more general, this has to do with GC being something that needs to interrupt execution to change things.
Like a green threading scheduler.
1
1
GC is your code running (lightweight) concurrently with a collector "thread"
1
Yeah, I was kind of wondering if it is like how people learn that single element lists and map/flatMap are handy for expressing nullability in languages without an Option type. Do futures give me more 'structure' than I want for GC?
1
Algebraic effects+handlers do give you interruptable sequencing, afaik (does depend on your system though).
1
Yeah. Bear in mind, the problem being solved here is "rust doesn't like GC bc it pulls the rug out under it"
and async as a solution is good because it is language support for pulling the rug out from under things
1
1
Whether or not it's too much structure depends on what you're using GC for imo. Though "too much" is fuzzy bc the alternatives aren't necessarily great.
1
I think it may work for servo (perf willing) because servo splits out most of its logic out of the dom, and the dom mostly wraps things and does tree manips. It's still *complicated*, but not pervasive.
1
Replying to
Yeah. I think this is a cool insight at any rate. Could make it easier to work with in Rust at least, given all the work going into async/await.
Replying to
Yeah, this is very much a "this improves rust" thing, if you're able to add first class language level support there are easier routes to go
(Though as Graydon mentioned runtimes often internally treat async and GC interruption points similarly)
1
1
Yeah, I've been considering adding algebraic effects to my hobby language, and was considering using effects for allocators. This gives me more encouragement, so thanks for sharing! (It's not all roses though - I want zero-overhead handlers somehow, which is kinda tricky)
1
1
Show replies