742570 - Better shell tests for GC

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Shell testing of new GC stuff isn't great right now. These patches try to improve that.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: 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.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: jsfriendapi changes

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.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: 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).

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: 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.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/94efe1ec3367
https://hg.mozilla.org/integration/mozilla-inbound/rev/bc7f3c676626
https://hg.mozilla.org/integration/mozilla-inbound/rev/15a23c3923ff
https://hg.mozilla.org/integration/mozilla-inbound/rev/a0a7af840b83

Comment 6

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/94efe1ec3367
https://hg.mozilla.org/mozilla-central/rev/bc7f3c676626
https://hg.mozilla.org/mozilla-central/rev/15a23c3923ff
https://hg.mozilla.org/mozilla-central/rev/a0a7af840b83

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4686dc4138ba