You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To support #2615 , specifically the second half of #2660, we need to give liveslots access to a platform-level gc() function that forces a garbage collection.
Description of the Design
On Node.js, this involves calling node --enable-gc, and we'll have to figure out some way to make sure it gets invoked that way. For xsnap (our XS runner), we need to uncomment a few lines that are currently disabled.
This changes the snapshot format: it adds a new "callback" (host-provided C function) to the start-compartment global, which must be recognized during serialization (and attached to something during reload). So we should do this sooner rather than later.
Security Considerations
We wouldn't want to expose this to user-level code (not that they could do much with it other than slowing down performance), but SES should filter it out from the globals in all but the start compartment. We should probably have a test to ensure it doesn't appear on a child compartment global by mistake.
Test Plan
A unit test that invokes it and makes sure it doesn't crash. Other #2615 unit tests will probably depend upon this gc() actually doing something.
The text was updated successfully, but these errors were encountered:
Modify xsnap.c to add a `gc()` function to the globals of the
initial ("start") Compartment. This function should trigger an immediate,
synchronous, full GC sweep. As a non-standard global, the `gc()` function
will be filtered out of the globals in all child Compartments by SES as
usual.
Note that this changes the snapshot format: heap snapshots written before
this change cannot be read by code after this change. This happens because
`gc()` (which is implemented in C) is a new "callback" (a C function made
available to JS code), which is an "exit" from the reference graph. It must
be recognized during serialization, and re-attached during reload, and xsnap
cannot handle loading snapshots with a different set of exits, even purely
additive changes.
closes#2682
refs #2660
refs #2615
Modify xsnap.c to add a `gc()` function to the globals of the
initial ("start") Compartment. This function should trigger an immediate,
synchronous, full GC sweep. As a non-standard global, the `gc()` function
will be filtered out of the globals in all child Compartments by SES as
usual.
Note that this changes the snapshot format: heap snapshots written before
this change cannot be read by code after this change. This happens because
`gc()` (which is implemented in C) is a new "callback" (a C function made
available to JS code), which is an "exit" from the reference graph. It must
be recognized during serialization, and re-attached during reload, and xsnap
cannot handle loading snapshots with a different set of exits, even purely
additive changes.
closes#2682
refs #2660
refs #2615
What is the Problem Being Solved?
To support #2615 , specifically the second half of #2660, we need to give liveslots access to a platform-level
gc()
function that forces a garbage collection.Description of the Design
On Node.js, this involves calling
node --enable-gc
, and we'll have to figure out some way to make sure it gets invoked that way. Forxsnap
(our XS runner), we need to uncomment a few lines that are currently disabled.This changes the snapshot format: it adds a new "callback" (host-provided C function) to the start-compartment global, which must be recognized during serialization (and attached to something during reload). So we should do this sooner rather than later.
Security Considerations
We wouldn't want to expose this to user-level code (not that they could do much with it other than slowing down performance), but SES should filter it out from the globals in all but the start compartment. We should probably have a test to ensure it doesn't appear on a child compartment global by mistake.
Test Plan
A unit test that invokes it and makes sure it doesn't crash. Other #2615 unit tests will probably depend upon this
gc()
actually doing something.The text was updated successfully, but these errors were encountered: