@Peter Huene question for you on the pooling allocator, right now there's a ModuleLimits
which is the maximum size of the VMContext
effectively and performs some other validation when compiling modules, out of curiosity what would you think if we did away with this entirely (or almost entirely) by instead saying "a VMContext
in the pooling allocator gets up to N bytes of storage"?
This came up here ish along the lines of making the pooling allocator easier to use where it would probably be more flexible to say that the instance slot is N bytes large and we provide a nice error during instantiation if the instance's VMContext
exceeds the size allocated for it
I think that makes total sense. Far easier to reason in terms of how much space instances take up when it's just two numbers to multiply as well. I'm all for less configuration knobs.
Would really help fuzzing logic too
Can totally do away with the limit enums all together
The instance one is a holdover anyway when there was more than just the count
ok cool I'll look into implementing this
Last updated: Dec 23 2024 at 13:07 UTC