Remove legacy heap region from snapshot #1697

Activity

1. syntactically

   added this to the 1.0 milestone on Jul 30, 2026
2. syntactically

   added

   area/performanceAddresses performanceAddresses performance

   lifecycle/confirmedBug is verified or proposal seems reasonableBug is verified or proposal seems reasonable

   on Jul 30, 2026
3. syntactically

   added the

   Bug

   issue type on Jul 30, 2026
4. syntactically

   added a parent issue on Jul 30, 2026

   • Snapshot-First Sandbox Lifecycle #1268
5. syntactically

   added this to Hyperlight Roadmapon Jul 30, 2026
6. syntactically commented on Jul 30, 2026

   

   syntactically

   on Jul 30, 2026

   MemberAuthor

   More actions

   There are a number of options for how we could do this:

   • Keep the current situation at the API, where there is a config-controlled heap size knob that sets the size of a VA reservation, but just find a way to avoid actually materialising it in the snapshot when it isn't needed
     • This could itself be done either by moving the VA region out of the currently-originally-identity-mapped-copy-of-snapshot space; or
     • We could leave it in place in VA space but change the PA space to not have that space, and making the original snapshot copy not-identity-mapped. There might be some slight perf benefit to this due to keeping the VA space more compact
   • We could make the heap region "unbounded" (well bounded only by the scratch size available in a given run) by moving it to a new very large VA space and populating it on demand. Because the current allocator is not very good, I am not sure whether this might have some negatives for its performance/minimizing its memory demands.
   • We could also make the heap region "unbounded" by moving it but only initialise the LockedHeap with a small subset of it, and then wrap the LockedHeap's allocator to hurriedly call add_to_heap whenever an allocation failed. We would have to double-check that the allocator's internal invariants allow ths.
   • We could switch our allocator entirely to a different one (see Change our no_std allocator #343) that supports the more common large-system allocator pattern of, rather than having a fixed backing memory region, asking the "kernel" to provide some more memory when it runs out.