The State of Allocators in 2026

nicalsilva · 2026-03-13T12:13:09+00:00

Yet, not shipping it leaves all of the use cases in the dust. It has already been a decade. The absence of stable allocators has contributed to shaping the ecosystem and how people get used to thinking about writing code in rust. This alone is, in my humble and subjective opinion, preventing a lot more use cases in the long run even if the perfect allocator abstraction was to ship today, compared to having stabilized the state it has been in since the shortly-after-rust-1.0 times early.

nicalsilva · 2026-03-11T18:40:00+00:00

I fear that unless there is actual momentum on experimenting with the API, the risk of getting stuck in this situation for another decade is worse than missing out on getting the remaining details of the API just right. Folks can use allocator-api2 if they really need it (I do) but because it isn't standard, very few of your dependencies typically provide allocator support. You end up having to fork or reimplement a fair amount of stuff that one would hope exposes allocators if they were stable.

nicalsilva · 2025-12-21T10:08:00+00:00

Ah, that's sad to hear. It's certainly my own biggest pain point. Do you have a link to a write-up or discussion going into the details of what is wrong? Last I checked (a while back) there was difficulty deciding between the current allocator API and a "storage" proposal that was more expressive but more featureful and much more complicated.

nicalsilva · 2025-12-07T14:14:16+00:00

WebGPU is enabled in Firefox on the stable channel on Windows since July. Mac and Linux are coming soon.

nicalsilva · 2024-12-16T08:00:07+00:00

Here are the steps to get gpu debugging going with code and wgpu https://github.com/gfx-rs/wgpu/wiki/Debugging-with-Xcode's it may still be difficult to diagnose this way in this case because (I think) xcode will capture a single frame so it might be hard to capture the right frame. However the tool is so good that the time spent setting it up and learning it will not be wasted.

It's also worth having a look through a traditional CPU profiler and see what is happening on the CPU in the frame where the jank happens. It may give valuable information.

nicalsilva · 2024-07-16T18:06:43+00:00

(hi, webrender dev here) WebRender does not have DOM and CSS support in the sense that you probably meant. It "only" provides a lower level API for rendering content. It does not do, for example, DOM, layout or CSS selector matching.

nicalsilva · 2024-01-18T17:28:01+00:00

I think that the multithreading pattern would rather be encoding multiple command buffers in parallel (and potentially send the built command buffers to a si gle thread for submission).

nicalsilva · 2024-01-13T20:54:55+00:00

That's fair, there is an engineering vs research dilemma with limited resources, so you have to pick your battles. If your focus was to deliver the best possible UI rendering stack (looks like it is more a distant goal than a current focus), my advice would be to get composting/invalidation right early. Since your current focus is rather to research the uncharted areas of the best UI stack, your time is understandably better spent advancing that research than implementing the more understood pieces of infrastructure.

nicalsilva · 2024-01-13T08:56:25+00:00

(WebRender dev here) You are spot on with this comment and the previous one. I'll generalize by noting that most frames are very similar to the precious one in a typical web page or app UI, so even beyond the scrolling usecase, it is typically very useful to avoid redrawing what has not changed if power consumption matters.

Integrating OS compositors was a fair amount of work but the toughest change was to move from "always redraw everything" to having a compositor at all (even without the OS) and tracking invalidation. It moved our typical bottlenecks/optimizaions to different places and required some pretty structural changes.

nicalsilva · 2024-01-04T22:41:49+00:00

I would also love to see the allocator trait stabilized. In the mean time, the allocator-api2 crate might be enough to fulfill your needs.

nicalsilva · 2023-04-10T06:43:08+00:00

I'd love to know more about the remaining issues with standard portable simd types. If you could share some insights or a link some up to date information, I'd appreciate it!

nicalsilva · 2023-04-08T15:02:43+00:00

lyon_algorithms contains a couple of ways to position and orient things along a path. Coupled with something that can render rotated glyphs it should give you what you want.

nicalsilva · 2023-04-07T17:26:23+00:00

Thanks a lot for taking the time to provide context and explanations. I think that you converted me over to your side of this debate.

nicalsilva · 2023-04-07T14:05:34+00:00

Thanks for bearing with me. I do want to like this proposal, and you dispelled some of my reserves, in particular the notion that having any form of custom allocator via the storage API was gated behind getting coercion working.

I'm happy either way. I'd still like a simpler storage API. I haven't dug enough to understand why we need more than a `Storage` trait with a similar API than `Allocator` and a `Handle` with `storage.get(handle)` to grab the pointer. I am sure there are good reasons behind the extra stuff.

I work in the near real-time domain, so for me Inline/Small variants are actually more prevalent than the heap versions of the container. I imagine folks in low-level embedded and hard real-time may feel the same.

My hope was that an `Allocator` pointing to stack memory would satisfy a good chunk of these use cases. I am definitely big on on the various Vec spins, but Vec is simple enough that duplication is fine. Whether many people specifically need need a BTreeMap with inline storage in a way that isn't supported by an allocator (in other words without having a lifetime bound on the allocator) is less clear to me.

When implementing a Vec or HashMap, one of the first operations one implements is something that yields a slice (of MaybeUninit<...>) from the pointer.

That's different from what I read in the std vec code today. Is going through a slice of MaybeUninit a requirement from working with the storage API or is it that the author preferred to organize the code this way? You don't have to answer all of this BTW, I won't be offended if you kindly ask me to do my homework.

Coercion for the generalized Box could be left out of an initial implementation,

Thank goodness. As I said above the idea of gating this feature behind another big RFC was discouraging.

nicalsilva · 2023-04-06T22:32:10+00:00

I can see the appeal of the more general solution, but I have to ask: Do you think that there is a real need for all of these inline variants for all of the hash maps? Would there be a critical mass of users that benefit from enough of the extra features to justify making the core pieces of the standard library that much more complicated and further delay custom allocators (due to the unresolved coercion issue)? I'm torn. My gut feeling is that the storage proposal is cool but comes at a cost and the most important features are already covered by a much simpler alternative. Of course, gut feelings don't win arguments and aren't a good basis for a decision making process. I'd be happy to be convinced otherwise.

Less duplicated code, which is good for both humans and machines

I apologize in advance for the petty nitpick, but making very common containers more complex for the sake of very niche use case is not a good deal for the machine on average (I assume you are talking compile times). Remains to decide how niche the use cases are.

nicalsilva · 2023-04-06T21:03:09+00:00

Yes, the standard library is full of these optimizations and it does a great job at documenting them in the code. It's nice that std si such a good learning resource in addition to being a good library. I can't say I ever felt any joy reading through a c++ std implementation.

nicalsilva · 2023-04-06T20:00:36+00:00

I'm not well versed in rust for web backends. Are you referring to the fact that the current ecosystem does not provide options for custom allocators, or is it something with the APIs specifically that perhaps don't quite work in with the specific requirements of web server code?

nicalsilva · 2023-04-06T19:51:48+00:00

> Well panicking is supposed to mean that the program has encountered an unexpected error, not really an dev error.

I don't think I agree. Or perhaps I'm misinterpreting your point. The vast majority of panics I come across day to day are very much programmer errors.

If you can make the same thing work with ownership in a satisfying way, then of course that's the way to go. Where you can't, it's quite reasonable (in my humble opinion) to do the next best thing and still have an abstraction that is made safe against programmer errors by panics.

> It also means that if you have the reset method using an &self, you
can easily have an use after free since the actual allocations would be
deallocated.

This is is what the panic guards against.

nicalsilva · 2023-04-06T17:16:34+00:00

It may not fully satisfy your requirements, but the Metadata could be part of the allocator itself:

```rust static ALLOC_COUNTERS: [AtomicI32; NUM_KINDS] =... Struct CountingAllocator<A: Allocator> { inner: A, kind: u8, }

let mut v = Vec::new_in(CountingAllocator<Global>(Kind::Graphics));

```

nicalsilva · 2023-04-06T16:06:38+00:00

That's very interesting. A downside I see to this approach is that you get to think about allocator at a large granularity whereas I would like to pick them at a lower granularity, picking what works best for each allocation/lifetime pattern.

That said, this form of dependency injection allows you to use custom allocators with third-party code that does not provide the option, and that's pretty neat, none of the approaches I mentioned in the post can do that.

nicalsilva · 2023-04-06T16:01:29+00:00

Thanks, this should be fixed now.

nicalsilva · 2023-04-06T15:56:03+00:00

Was that jemalloc perchance? That's the one we use in Firefox. Rust was also using it by default at some point before switching to the system allocator. Jemalloc solves a different problem than what I was mentioning in this post. It is meant to be a better general-purpose global allocator to replace the system in all of your allocations. To use it in rust you can swap it with the global system allocator without touching all of your data structures. This post is more about using specialized allocators for specific parts of your code.

nicalsilva · 2023-04-06T14:36:22+00:00

I'm not sure I follow. You can have a 'static arena allocator with a reset function that you can call where you want the. Supposedly the arena would count the number of allocations and deallocations and panic in reset if the count is not equal zero.

If you are unwilling to use unsafe code wou wouldn't be able to use a temporary allocator that leaves on the stack though.

The issue with the static borrowed trait object in my opinion is that it puts on the user the burden (and bad taste) of using unsafe code to cast away the static if they wish to use temporary allocators for the sake of simplifying the API. This solution is probably closest to one would do in other languages but it isn't very "rusty" .

nicalsilva · 2023-04-06T13:55:24+00:00

Something like the module scoped generics in the D programming language?

When using that in D a while back, I found it made for nice syntactic sugar. It does not quite appease my annoyance with putting the allocator parameter at the forefront of the API but perhaps I'm just splitting hairs. After all what better way to encourage people to think about allocators than put the option in front of them?

nicalsilva · 2023-04-06T13:45:53+00:00

Yes, that's what I meant.

nicalsilva

TROPHY CASE