Skip to content

Consider skipping GC heap decommits for same-type instance slot reuse #13838

Description

@tschneidereit

With the pooling instance allocator, we use virtual memory tricks to reset memories to their original size and discard their contents. For linear memories, both are important even when reusing the same memory for a fresh instance of the same type: the fresh instance mustn't observe stale contents, nor must it see a larger linear memory heap than expected.

For GC using instances, neither of these applies in the same way, so we could consider avoiding some of this work:

  • with the copying collector, to avoid making stale contents observable all we need to do is reset the bump allocator's offset to the beginning.
  • GC heaps don't have an observable upper bound the way linear memories do, since our use of wasm memories is an implementation detail to begin with.

What I'd propose is that we set the linear memory size for GC heaps to the configured maximum slot size right away (if we aren't already doing so; I didn't check that part) and skip decommitting for memories whose allocated size is < pooling-memory-keep-resident.

Note that AFAICT we're not applying instance type affinity to GC heap memories at all, so that'd have to change as well for this to be useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions