On 11/01/2013 10:48 AM, Steve Fink wrote:
Why? I agree, but only for some general reasons and some
dimly-remembered reasons that I've encountered in the past where the
implications turned out to be far worse than I would have initially
thought. I'd really like to have a crisp explanation of exactly *why*
exposing GC behavior is bad, because otherwise I feel like people will
end up deciding they can live with the minor drawbacks they can think
of, and proceed forward with something truly awful. (Like, for example,
exposing the current strawman to general web content.)
None of this is anything you couldn't think of yourself, but:
Our experiences exposing GC-sensitive APIs in Debugger have been quite
negative.
Debugger.prototype.findScripts scans arenas directly to build an array
of scripts that match a given query, so its return value depends on
which scripts have been collected at the time of the call. We've bumbled
into tests that begin to fail in response to no evidently relevant
change; problems we can reproduce in the browser but not the shell; etc.
The heart of the problem is that, while GC is unpredictable /in
principle/, in practice its behavior is often stable for long periods of
time, and perhaps even across platforms. If you write a test or some
code that happens to work despite being wrong in principle, it will
usually continue to work for quite some time. Perhaps even across
multiple platforms. Then, when some other change innocently shifts the
conditions, your test or code breaks.
Since the heap is this big shared thing, GC-sensitive APIs make it
possible for perfectly legitimate changes in one part of the browser to
affect the behavior of completely unrelated code.
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
