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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
