I don't believe this is really a good idea, but a workable approach could be
something like a scope directive which disallows collection, eg
```
function renderParty(scene) {
"disallow gc";
// no GC pauses here...
}
```
but, engine heuristics might be better able to choose more appropriate times to
collect. And, only really makes sense for synchronous code
> On Mar 12, 2016, at 8:52 PM, Boris Zbarsky <[email protected]> wrote:
>
>> On 3/12/16 8:08 PM, Brian Barnes wrote:
>> As for being a de-optimization hazard, that’s certain a problem, but we
>> shouldn’t disallow the usage of something because programmers are bad.
>
> It's not a matter of badness or goodness. It's a matter of programmer
> expectations not matching the actual engine behavior. Which is particularly
> easy to have happen when there are multiple engines that have _different_
> behaviors. Not to mention that engines might want to change their behavior.
>
>> It could certainly happen on a callback, too, which I think is perfectly
>> fine. As far as I know, most all gcs I’ve seen have different modes, small
>> gcs, and large gcs.
>
> I'd like to understand the proposal here better. What is happening off a
> callback? The gc, or code that wants to run after the gc?
>
> On another note, the above quoted text is a good example of my claim above
> about expectations and behaviors. The SpiderMonkey GC (the JS GC I know most
> about) has 3 modes, I believe: (1) collect just in the nursery, (2) collect
> in the part of the heap that contains objects from a predetermined set of
> globals, treating any cross-global references into that part of the heap as
> roots, (3) collect across the entire JS heap, treating references from C++ to
> JS as roots. When running in Firefox there is a fourth mode: collect across
> the JS heap but also run the cycle collector in Gecko to detect reference
> cycles that go through the C++ heap and collect those too.
>
> Which of those are small and which are large? And note that this set of
> modes is definitely not fixed in stone, and that for mode #2 the set of
> globals that constitute a single "zone" (what we call the sets in question)
> is not fixed in stone either across different Firefox versions...
>
> -Boris
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
