Shell testing of new GC stuff isn't great right now. These patches try to improve that.
Created attachment 612378 [details] [diff] [review]
remove compartment flag on gc zeal
A while ago we added a flag to allow gczeal GCs to be compartment GCs. However, it didn't allow you to select which compartment to collect, so it always just used the compartment that code was currently running in. We never actually found any bugs with this feature, and I never thought of a good way to use it.
I'll post patches below that give more control over which compartments get collected, and I think they supersede the gczeal compartment parameter. So I think we should remove it, since it adds complexity.
Created attachment 612381 [details] [diff] [review]
The current API doesn't support multi-compartment GC. This patch allows jsfriendapi to do multi-compartment GCs. It removes the possibility of compartment GCs from jsapi. I doubt that embedders were using it anyway.
One side effect now is that when you call a jsfriendapi GC function, you have to call other functions before it to specify which compartments to collect. If you don't do this, we'll assert.
Created attachment 612382 [details] [diff] [review]
changes to gc() and schedulegc()
This patch changes the shell functions for GC to allow for multi-compartment GCs.
Currently, schedulegc(n) schedules a GC after n allocations. This will allow you to do schedulegc(obj), and it will schedule obj's compartment for collection. I'm not sure if it makes sense to use the same name or not.
You can still do gc() (which always does a full GC) and gc(obj) (which collect's obj's compartment). But now you can do gc('compartment'), which collects any compartments that have been scheduled for gc via schedulegc(obj).
Created attachment 612402 [details] [diff] [review]
control incremental GC from shell
This patch makes it easier to control incremental GC from the shell.
First, it makes gcslice() work better. First, if you call gcslice() with no arguments, it finishes an existing incremental GC. (If there wasn't one already going, it does a complete GC.)
Also, it allows you to specify gcslice(0). If no incremental GC was running, it starts a new one but doesn't mark any objects.
The patch also allows you to specify objects that should be marked during the next incremental slice. This is really useful for writing test cases that require write barriers in order to be correct. I verified that the test case in this patch crashes if write barriers are disabled.