This doesn’t really solve the problem at hand; my code comes in two parts, the first generates a lot of objects, the second, generates almost none. The second part generates a 1-2 second paused GC *once* (because of the first part) and never again (because it constructs no more objects or only local primitives which can be collected more easily.)
Also, I don’t think you can ever be able to tell a gc type system to not collect during a certain point, it makes forced collections (because it’s completely out of memory) an error. So, I don’t want to pause gc; I want to tell it “do one now, please.” The exact same way it might do it if it’s run out of space. If you look at the application I sent out with this (http://www.klinksoftware.com/ws/ <http://www.klinksoftware.com/ws/>) it goes a long way to showing what I mean by all this. [>] Brian > On Mar 12, 2016, at 9:16 PM, Caitlin Potter <caitpotte...@gmail.com> wrote: > > 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 <bzbar...@mit.edu> 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 >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
