> 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.
You might be thinking of this too technically. The contract would be, if the engine is GC (which is likely, as I pointed out without compiling or additions to the language), then do as much clean up as possible. If the system isn’t GC, then the problem you are looking to solve — which is to make GC happen more predictably in special circumstances — is no longer a problem. For instance, you might have a system that has a flush() on it, this is something you see a lot. Depending on the actually physical storage method (sometimes an OS might have a file in flash and the flush means next to nothing, or an OS might always write though), but flush is STILL a useful and understood function. APIs do something; if that something is no longer necessary, than the APIs are noops. Flushes would be like that. > >> 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… Small and large GCs, in my parlance, would be in fact quick and full GCs; if you watch most GC system, you’ll get tons of little collections, and then, eventually, a large collection. Almost all GCs behave this same way. Contractually, though, this would be “every GC you can do, on any object you can.” In FF, it would go through everything it could. As for a callback, it would be after the GC has finished, or finished as well as it can. This does NOT counted threaded application; if you are running on web workers, or any other reason, than you would understand that all that can be cleaned is all that can be traced from your current execution. Maybe System.gc() is a bad name, if people are worried about a fundamental change to how a engine does memory management. System.memoryCleanUp() — OK, that’s awful :) [>] Brian _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
