Problem
Hyperlight-JS snapshots distinguish:
available: callbacks installed in the destination host
required: callbacks exposed to the current guest state and recorded in snapshots
Consider:
- Snapshot requires function A.
- Destination provides A and B.
- Restore preserves
required = {A} and available = {A, B}.
- A new handler that calls B is staged.
- The next snapshot must require both A and B.
Hyperlight-JS cannot reliably infer host-function dependencies from arbitrary
JavaScript. Imports and property access can be dynamic, and runtime observation
would miss unexecuted branches.
The current safe behavior conservatively promotes required to the complete
available manifest whenever a handler or module is added after restoration.
This is correct but can overstate requirements and reduce snapshot portability.
Proposed solution
Add an optional API for declaring host-function requirements when registering
handlers and modules. Track requirements per registered item so removals can
recompute the resulting union.
Callers that omit declarations retain the conservative promotion behavior.
Problem
Hyperlight-JS snapshots distinguish:
available: callbacks installed in the destination hostrequired: callbacks exposed to the current guest state and recorded in snapshotsConsider:
required = {A}andavailable = {A, B}.Hyperlight-JS cannot reliably infer host-function dependencies from arbitrary
JavaScript. Imports and property access can be dynamic, and runtime observation
would miss unexecuted branches.
The current safe behavior conservatively promotes
requiredto the completeavailablemanifest whenever a handler or module is added after restoration.This is correct but can overstate requirements and reduce snapshot portability.
Proposed solution
Add an optional API for declaring host-function requirements when registering
handlers and modules. Track requirements per registered item so removals can
recompute the resulting union.
Callers that omit declarations retain the conservative promotion behavior.