Bucket allocations by size in the free list

[fitzgen]

This allows us to avoid O(n) search for a block of a certain size in the worst case.

Follow up to #12969

[alexcrichton]

How worth it do you feel chasing improvements in allocation/deallocation performance are? My impression is that BTreeMap is quite large in terms of code size, pretty wasteful in terms of resources, and not really all that efficient. I think it's quite good at its job of reducing things to O(log n) algorithmic complexity but my impression is that the constant factors are quite high for micro-algorithms like a malloc and free which this more-or-less is.

Mostly in the sense that I continue to be worried that we can layer on more and more Rust data structures to make malloc and free faster but I'm worried about unintended consequences about how these all interplay with each other. For example if there were a lot of 4-byte gaps in the heap it might end up meaning that the BTreeMap to represent the free list was larger than the heap itself (or something like that). With this there's multiple layers of BTreeMap to consider and personally I inevitably get lost in the details.

All that being said complexity can still be justified and it's not like I know of anything particularly wrong with this approach. Mostly I wanted to at least ask though to get your temperature on this axis too

[fitzgen]

How worth it do you feel chasing improvements in allocation/deallocation performance are?

This PR is just to address your comment here, I have no intention to continue pushing on free list performance from this point on. My hope is that between #12969 and this PR, we will have gotten it to the point where performance of the free list itself is acceptable enough for enabling GC by default.

[fitzgen]

My impression is that BTreeMap is quite large in terms of code size, pretty wasteful in terms of resources, and not really all that efficient. I think it's quite good at its job of reducing things to O(log n) algorithmic complexity but my impression is that the constant factors are quite high for micro-algorithms like a malloc and free which this more-or-less is.

Mostly in the sense that I continue to be worried that we can layer on more and more Rust data structures to make malloc and free faster but I'm worried about unintended consequences about how these all interplay with each other. For example if there were a lot of 4-byte gaps in the heap it might end up meaning that the BTreeMap to represent the free list was larger than the heap itself (or something like that). With this there's multiple layers of BTreeMap to consider and personally I inevitably get lost in the details.

This is all true, but note that the fast path is just bump allocation which doesn't touch the btrees; we only go to them when bump allocation fails.

Ultimately, I think there is definitely room for improvement here as far as allocators go, but this should get us to a decent state and then the self-hosting would be the next step for this code.

[github-actions]

Subscribe to Label Action

cc @fitzgen

Details

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"

Thus the following users have been cc'd because of the following labels:

• fitzgen: wasmtime:ref-types

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.