# Gate-2 slice: the ExpandingHeapAllocator family -- the allocator LAYER
# only. The Heap class layer above it (CreateRootHeap, SetupRootHeap) reads
# OS arena globals and waits for the OS seam in a later gate.
#
# Chosen second because Andrew's implementation order starts at
# memory/runtime/heaps, and because this is where the LP64 bug class lived:
# an allocator that survives a fill-pattern torture test on the host is the
# strongest layout evidence a port can buy per line of test code.

src/engine/heap/ExpandingHeapAllocator.cpp

# NestedHeapIterator: the shared HeapAllocator initializer registers every allocator
# in the global nesting registry, so the iterator family rides along. The fold put
# all of it in one TU, which now also supplies func_0204df54 (that initializer)
# and HeapAllocator::Remove.
src/engine/heap/NestedHeapIterator.cpp

# The allocator entry points the ExpandingHeap overrides forward to (the
# seventh, HeapAllocator::Remove, now arrives with the NestedHeapIterator TU
# above). They
# arrive with those overrides (slice_gate3a.txt) rather than because gate 2 grew:
# each V* method is a one-line call into this layer, so a host link that has the
# override and not its target has half of a pair. They stay HERE because this is
# the allocator layer's manifest and smoke_heap links it, which is the gate that
# would catch a break in them first.
src/_ZN22ExpandingHeapAllocator16InvokeDeallocateEPvPS_j.cpp

# cstd::abs, which ExpandingHeapAllocator::MaxAllocatableSize calls. It was in
# slice_gate4b.txt and moved here rather than being listed twice: the nine targets
# that link gate 4b all link gate 2 as well, so two entries would be a duplicate
# definition, and the layer that needs it first is this one.
src/_ZN4cstd3absEi.cpp
