> On Mar 12, 2016, at 10:05 PM, Boris Zbarsky <[email protected]> wrote: > > On 3/12/16 9:52 PM, Brian Barnes wrote: >> This is key: >> >> 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. > > User code creates lots of objects in Firefox whose memory management model is > not mark-and-sweep at the moment (for example, DOM nodes). > > The docs you are looking at there are specifically for SpiderMonkey, not > SpiderMonkey in a particular (browser) embedding.
We’re closing in on something! This could have been clearer on my end; I am looking at only javascript objects. My code, for instance, interacts only though a webgl context; it never creates any nodes or does anything outside of javascript. I think that would be way outside scope and not something you’d want to have in the GC scope, anyway. I think anybody that called a gc() inside javascript code would assume that was the case. > >> I think this is all that needs to be done. > > Not if you're actually trying to avoid memory collection pauses, sorry... > This is what makes all this rather annoying. > >> 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. > > OK. Note that you can have some control over things the browser creates too, > not just things you create. > > But again, the definition of "GC" as described on the page you link to > doesn't cover everything that's touched by "GC" as it matters for an actual > page in a web browser… Yeah, again, I think this is where we are bumping heads over. I never meant it to matter at all to what goes on in the browser, just objects created in code. This, basically: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GC <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GC> Having System.gc() call that would solve my problem (I think.) > >> 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. > > OK. Say I have some gc pauses: 100us, 1ms, 5ms, 10ms, 20ms, 50ms, 600ms. > > Which of those are quick pauses and which are large? As far as I can tell, > the answer depends on the application, what sort of real-time guarantees it > needs, and how much processing it does itself. About the only thing everyone > would agree on is that 100us is small and 600ms is large. > >> But this has de-evolved; let’s reduce this to the regular mark-and-sweep >> collection of objects. > > That would correspond to the first three modes I described, but even within > that a given mode can in theory lead to either a quick pause or a large one, > and you don't necessarily know up front which it will be. > > In practice, all the modes are incremental and aim to not have anything > resembling 600ms pauses. But if 5ms constitutes a "large" pause for you, > then you might end up with "large" pauses from at least two of the modes. > Not sure whether a nursery collection can ever end up there... > > But my larger point is that if we define this to be "regular mark-and-sweep > collection of objects" that might well not be enough to avoid big memory > collection pauses in the future anyway. And if we don't define it to be > that, then it's not clear what to define it to be because it really depends > on what else is going on… Honestly, I never thought I’d get into this discussion. I always saw this as something that would be different, from engine to engine, as engine GCs are different. The end user doesn’t have a lot of control or knowledge of the mechanics of such things. System.gc() would be the same thing. I know “nebulous” when it comes to an API is weird, but GC per-engine is different and unpredictable (not really, but to a human, yes.) It would have to do something for every javascript engine, so it wouldn’t be something you could just spec as x/y/z. Best case, to clean up and compact the heap for the code you are currently running in. [>] Brian
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
