-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⁉️ Switch to using the on-demand allocator, instead of the pooling allocator #391
Conversation
Interestingly, we've always used the pooling allocator: Lines 74 to 78 in f44257f
Should we integrate the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Limiter
changes look good to me, but I think we need a StoreLimits
on ExecuteCtx
as well, to ensure that we're enforcing limits on core wasm execution.
Ignore my comments about neeing a |
@@ -90,7 +140,7 @@ impl ComponentCtx { | |||
wasi: builder.build(), | |||
session, | |||
guest_profiler: guest_profiler.map(Box::new), | |||
limiter: Limiter::default(), | |||
limiter: Limiter::new(100, 100), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need to change this, but I'm not too worried about it now as we're not officially supporting components yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
…locator (fastly#391) Fixes fastly#255. In addition to just fixing fastly#255, this also allows the test suite to be run in parallel, again. At least on my machines, running `make test` directly would cause memory failures. I'm guessing this was due to the pooling allocator's use of virtual memory. Switching to the on-demand allocator means that things run fine. This extends the built-in `Limiter` object to use a `StoreLimits` under the hood, as suggested in the issue. It then builds different versions of this limiter based on whether or not Viceroy is operating in a component or non-component context, because component-based systems require more instances and more tables than traditional ones.
Fixes #255.
In addition to just fixing #255, this also allows the test suite to be run in parallel, again. At least on my machines, running
make test
directly would cause memory failures. I'm guessing this was due to the pooling allocator's use of virtual memory. Switching to the on-demand allocator means that things run fine.This extends the built-in
Limiter
object to use aStoreLimits
under the hood, as suggested in the issue. It then builds different versions of this limiter based on whether or not Viceroy is operating in a component or non-component context, because component-based systems require more instances and more tables than traditional ones.