And there is tokio::spawn_local() that doesn't require Send
Do you have measurements to back that up? I would expect it to be a lot cheaper than GC because GCed language such as Java/Go/etc. GC every heap allocation (and Java in particular doesn't have unboxed objects, so there are a lot of heap allocations!) where Arc<RequestState> would bundle a bunch of things together.
That said, I'm not in love with the Arc solution either. It's not just the performance impact. The programming model of scoped concurrency is just much more pleasant. Giving up that and then also having to deal with putting everything into an Arc, and likely also then wrapping it in a MutexLock, even when it should really be one thread at a time dealing with the value in question, just doesn't do anything good for readability and writability of code...
GC is not run on every allocation.
This is more a Java problem than a GC problem; C# supports values just fine, and some heroic JVM-targetting languages also manage it.
> RC languages do need to free memory used to hold the values later
It also has arena allocators, so you can group allocations that will be freed at a similar time. You don't need to walk through these to find them all and individually free them. Anything with a Drop impl (destructor) gets thrown on a list for that to be taken care of; then the arena's relatively few, large blocks get freed all at once.
I've used this in C++ to squeeze the last bit of performance out of a high-request-rate server. I haven't done it in Rust, but it's the same idea.
btw, little confused by this:
> [RC languages?] have to run expensive compaction and locking steps
Was this meant to refer to GC languages? I've never seen one that does compaction (we're talking about the same thing? moving all the memory allocations around to reduce fragmentation?) That's more of a GC language thing that e.g. Java does; it would require the language/runtime to be able to precisely spot pointers and be able to throw in a trap when one it's changing is dereferenced or to entirely stop the world first.
Well, there is boehm if you do want to take on that complexity. But no, I am referring to the book keeping operations that are done internal to the malloc and free calls. They are largely hidden from you as the user of the API, but you still have to pay for them in runtime.
I thought rust didn’t have any safe arena allocators, but that some people make them by tricking the system with indexes instead and such, though word was they might come soon https://news.ycombinator.com/item?id=33403324
Under modern garbage collection, there's very little need to coordinate across cores, just some barriers every now and then to mark things safe.
If you're talking about Arc<GlobalStuff>, I'd probably use Box::leak instead. There's also a few crates that do epoch gc. I haven't really written super high request rate multicore stuff in Rust, but I have in C++, and there for global-ish occasionally updated config stuff, I used a epoch gc implementation on top of Linux rseq to totally eliminate the effect you're describing.
Arc makes otherwise read-only activity write.
In this case, the Linux rseq-based epoch GC worked perfectly. It is technically a form of garbage collection, but it's not all-or-nothing like Java-style or Bohm GC; it's just a library you use for a few highly used, infrequently updated data structures.
This can't be implemented robustly, because there's no way to enforce the outer scope (the one lending its stack) won't return while the futures are still running. It needs a blocking mechanism that does "wait, your async code hasn't finished yet!", but implementing that via guards and destructors can be bypassed by leaking them.
https://without.boats/blog/the-scoped-task-trilemma/
----
However, running futures on the same thread, with a simple plain .await, does allow them to borrow from the caller's stack safely without restriction. So the first poster in this thread may be doing something unusual, perhaps just over-using multi-threaded spawn() where join_all or streams would suffice.
If this is mostly about scoped async task and the ability to reference data from the parent task, then there also had been a different proposal being discussed which provides the same guarantee: A new Future type (e.g. CompletionFuture), which by represents an async function that needs to be driven to completion. See https://github.com/Matthias247/rfcs/pull/1 for details. However since this propsal is already 3 years old and hasn't gotten and interest by the Rust async WG, it's probably also not going forward.
The problem with not having Leak is that it forces all futures to be ‘static, which effectively disables the borrow checker whenever you cross an async spawn boundary.
Arc is the standard solution, but, for multi-threaded code, it can be expensive (though also more predictable, in fairness) than having a GC.
The only other solution (which I prefer) is to use an unsafe version of spawn that assumes the future it returns will not be leaked.
This certainly breaks the rust promise of supporting safe, zero cost abstractions.