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).
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.
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).
-Boris
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
