> On Mar 12, 2016, at 9:31 PM, Boris Zbarsky <[email protected]> wrote: > > On 3/12/16 9:11 PM, Brian Barnes wrote: >> 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. > > What does that mean, exactly? In the case of SpiderMonkey+Gecko, should that > run the cycle collector? Should it run it multiple times (it might take > multiple cycle collector runs with GC in between to collect everything that > could be collected by a future collection). Should it evict caches that can > cause things to become garbage when they get evicted? Should it perform > maximal heap compaction (and therefore need slow heap growth on future > allocations)? > > Is this "as much cleanup as possible" allowed to take tens of seconds of > wall-clock time, which is what you might need in some cases to really make > sure you've found all the garbage? > > And will people who make the call really expect all that to happen?
> >> 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 > > The problem is that "GC" isn't a single thing that can happen. It's multiple > different things that can happen, and have vastly different heuristics. It's > not even necessarily clear which tasks fall under "GC" and which do not (c.f. > cache evictions above). This is key: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management> When the mozilla docs refer to GC, they refer to mark-and-sweep objects created by the user’s code. I think this is all that needs to be done. No weak references, either. There’s certain other things that goes on, but they are things out of control of the coder. The objects the code creates are what we are interested in. > >> 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. > > That's because the operation is controls is somewhat simpler than "collect > all the memory" (though in practice flush() is not actually understood in > terms of what it means about the bits actually being in non-volatile storage > or not....) > >> APIs do something > > Sure. Whether that something is what you wanted, or even what _anyone_ wants > is a separate question. > >>> 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 > > I just pointed out that SpiderMonkey has 3 or 4 different kinds of GCs, which > scale from "fast" to "slow". More if you include things like cache eviction. > You came back with, again, wanting to categorize things into two buckets. I > feel like we're talking past each other. > >> if you watch most GC system, you’ll get tons of little collections, and >> then, eventually, a large collection. > > Note that I pointed out a specific production JS implementation, a fairly > widely used one, where this is not exactly how things work. As in, I'm not > raising a theoretical objection to assuming this model here. We’re not talking past each other, we are talking at different levels of grain. I’m talking about what the end user experiences; which is numerous quick GCs usually followed by a large GC. You are talking about the actual mechanics of what each of those GCs actually are, or do, but to the end user, they are quick pauses and large pauses. But this has de-evolved; let’s reduce this to the regular mark-and-sweep collection of objects. > >> Contractually, though, this would be “every GC you can do, on any object you >> can.” > > See my questions above. > >> In FF, it would go through everything it could. > > I really don't think you want an API that would take tens of seconds to run > in some cases, which is what you're asking for here. > >> As for a callback, it would be after the GC has finished, or finished as >> well as it can. > > Ah, to avoid requiring stopping the world. That's good, sure. Maybe then > you really _are_ OK with it taking a long time ...or never completing, if > garbage is created between each async gc slice so we never "finish". > >> 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 :) > > Note that Firefox _does_ have some built-in "minimize memory usage" thing > (you can get to it from about:memory). This is an async operation that will > in fact go through all renderer processes and ask each of them 3 times (3 > because 1 is not enough per comments above and we didn't really want an > unbounded number) to flush all caches, do collection, etc. > > I just tried it; took about 15 seconds with my set of tabs.... And of course > it clears all caches (so likely throws out things you might in fact care > about). Yes, I have no problem with it taking a long time, that would be part of the contract. It’s possible it could be also updated with the notion of how much recursion it should take, like: System.gc(recursionCount,callback); [>] Brian
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
