624640 - Browser-based gczeal is a trap for the unwary

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

Attachment: Reset gczeal(0) on page unload to get back to a speedy state

It changes GC zeal for all time, not until the next test occurs.  This is bad.  It's not at all what I would have expected, and it caused a change I made to produce inexplicable tinderbox timeouts, at least until I debugged this.  Nobody should have to make this mistake.

Comment 1

[Luke Wagner [:luke]]

Future-luke thanks you.

Comment 2

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/tracemonkey/rev/e272d471f4c4

Existing tests will continue to reset gczeal, don't think that needs to be fixed now (or indeed ever, actually, but we might still want to do it so people learning by example don't think entirely wrongly).

Comment 3

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/e272d471f4c4

Comment 4

[Bob Clary [:bc] (inactive)]

fyi, with this change it is no longer possible to run the full suite under gczeal 2.

Comment 5

[Jeff Walden [:Waldo]]

Hm, point; that's not ideal.  We could sample gczeal at test start, then restore to that original value at test end.  And perhaps we should change the current imperative mode of gczealing to something functional that could restore the original zeal, not just clear to 0 -- withZeal(2, callback) -- although I'm less certain about whether this or something else would be preferable.  Mind filing the followup to do this?