You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The custom-page-size feature is a standard proposal that overlaps with the current shrink_memory implementation based on heap_base in wasm_loader.
The unresolved question is whether we should retain both features or just maintain one
Given that shrinking memory is not a standard operation, yet there is consistently a need to reduce memory usage, should we make it controllable and/or configurable? For instance, by using a compilation option and/or a command line option.
The text was updated successfully, but these errors were encountered:
Given that shrinking memory is not a standard operation, yet there is consistently a need to reduce memory usage, should we make it controllable and/or configurable? For instance, by using a compilation option and/or a command line option.
it makes sense.
while custom-page-sizes might be able to replace it in future, it's far from ready today.
The custom-page-size feature is a standard proposal that overlaps with the current shrink_memory implementation based on heap_base in wasm_loader.
The unresolved question is whether we should retain both features or just maintain oneGiven that shrinking memory is not a standard operation, yet there is consistently a need to reduce memory usage, should we make it controllable and/or configurable? For instance, by using a compilation option and/or a command line option.
The text was updated successfully, but these errors were encountered: