Bug 99107 – BlockAllocator should use regions as its VM allocation abstraction

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Hahnenberg]

Currently the BlockAllocator allocates a single block at a time directly from the OS. Our block allocations are on the large-ish side (64 KB) to amortize across many allocations the expense of mapping new virtual memory from the OS. These large blocks are then shared between the MarkedSpace and the CopiedSpace. This design makes it difficult to vary the size of the blocks in different parts of the Heap while still allowing us to amortize the VM allocation costs.

We should redesign the BlockAllocator so that it has a layer of indirection between blocks that are used by the allocator/collector and our primary unit of VM allocation from the OS. In particular, the BlockAllocator should allocate Regions of virtual memory from the OS, which are then subdivided into one or more Blocks to be used in our custom allocators. This design has the following nice properties:

1) We can remove the knowledge of PageAlignedAllocations from HeapBlocks. Each HeapBlock will now only know what Region it belongs to. The Region maintains all the metadata for how to allocate and deallocate virtual memory from the OS.
2) We can easily allocate in larger chunks than we need to satisfy a particular request for a Block. We can then continue to amortize our VM allocation costs while allowing for smaller block sizes, which should increase locality in the mutator when allocating, lazy sweeping, etc.
3) By encapsulating the logic of where our memory comes from inside of the Region class, we can more easily transition over to allocating VM from a specific range of pre-reserved address space. This will be a necessary step along the way to 32-bit pointers.

This particular patch will not change the size of MarkedBlocks or CopiedBlocks, nor will it change how much VM we allocate per failed Block request. It only sets up the data structures that we need to make these changes later when we have more performance data.

[Mark Hahnenberg]

Created attachment 168300 [details]
Patch

[Geoffrey Garen]

Comment on attachment 168300 [details]
Patch

r=me

[Mark Hahnenberg]

No change in performance according to the benchmarks we track.

[WebKit Review Bot]

Comment on attachment 168300 [details]
Patch

Clearing flags on attachment: 168300

Committed r131132: <http://trac.webkit.org/changeset/131132>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.