> On Mar 13, 2016, at 5:16 PM, Boris Zbarsky <[email protected]> wrote: > > On 3/12/16 10:52 PM, Brian Barnes wrote: >>> What I'm trying to say is that it may well not, if it just called JS_GC and >>> if the problem to be solved is pauses on the order of several tens to >>> hundreds of milliseconds due to memory collection activity… >> >> Time is not my concern. I’m trading time now for time when it’s critical. > > I understand that. What I am saying is that if you call JS_GC now, that > doesn't mean that a cycle collection won't happen 30 seconds from now. To > help prevent that, you'd have to run cycle collection now. > > In other words, JS_GC would help somewhat in your situation, but not > completely. And maybe tomorrow it would help less than today. Or maybe more…
“Perfect is the enemy of the good.” I’m asking for a specific, useful function, not the perfect solution to my problem. The perfect solution is more complex, and requires things like never allocating any other large objects, or sometimes any objects at all. This I *have to do now.* There is no way around it. In the future, I might not have to, and it’ll be wasted code, but now, I *have to* as does anybody else that wants time sensitive code. > >>> OK, but then we run the very real risk of it not actually doing what people >>> want. Or more precisely browsers implementing it in various different ways >>> as they attempt to map its not-really-defined semantics onto their actual >>> GC systems and then people sprinkling it about based on the GC heuristics >>> and setup in one particular browser they tested with and optimized for, and >>> then other browsers having to reverse engineer those _and_ that one browser >>> being locked into never changing how its GC operates. >>> >>> And then we all lose. :( >> >> That’s modern web development > > No, I don't think it is. The way we prevent problems like this from arising > is by actually creating standards, so that browsers know what behavior they > need to have and consumers know what behavior they can depend on. > >> my code uses classes, and I had to fake them until FF 45 came out, and then >> realized they failed unless I was operating in strict under chrome; Safari >> doesn’t have let and nobody has proper implementation of stereo panning in >> web audio :) > > Yes, but these are transitional problems. I'm talking about it being a > problem when current implementations constrain both each other and future > evolution of themselves because someone comes to depend on undocumented > details of them. > > This _also_ happens in web development, but it's something no one likes to > happen.... > >> Not asking for miracles; I’m asking for best practice on an engine. > > The problems start when the best practice is different for different engines > and people optimize their code based on only one engine. That’s not our problem, and that’s not a solvable problem. Every engine will try to get ahead by some manner, and something like compiling, or GC, which isn’t spec nor should it be, will always be evolving. A System.gc() will in no way constrain further development. It’s not a guarantee to do anything but “free up objects that are no longer reachable and compact the heap.” Period. If there is no longer a heap, or no objects to free, it’s a noop. The contract is not “make my code run faster.” It’s not “don’t do it again in a little bit.” It’s not any of those things. I think you’re trying to force the API to be a problem solver; my problem is just a reasoning why it’s useful. Small contract: Free up objects that are no longer reachable and compact the heap, the objects being objects that aren’t attached by outside APIs (DOM, webgl, web audio, etc.)” [>] Brian _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
