> On Mar 12, 2016, at 10:32 PM, Boris Zbarsky <[email protected]> wrote: > > On 3/12/16 10:22 PM, Brian Barnes wrote: >> 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. > > But it creates WebGL objects like WebGLUniformLocation or WebGLTexture? > Because those aren't mark-and-sweep either... They're much more like DOM > nodes in terms of their memory management. > >>> 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. > > I think we might have different definitions of "objects created in code". > Are you including return values from getUniformLocation?
That’s my problem. All uniforms, all textures, are created once, rooted in my classes, and are never meant to be GC’d. They are not created on the fly. This is something you need to do to reduce GCs, and most game engines work this way, or they re-use these objects. This is a problem solvable at my level and just regular OpenGL programming outside of the language you use. Remember, I’m not asking for a perfect solution; GC is mysterious in a number of ways, and they might be collectable on different engines, you never know. I’m asking for best practices. Anything that I think of as a DOM object I understand is something that operates differently. Knowing which is which will probably be an engine detail; we can’t stop engines from being different. Minutia in an API is something that happens. What’s a good way to say this? “Javascript objects attached only in your code.” Things like web audio, webgl, DOM elements, etc, don’t count, for example: this.vertexPositionAttribute=view.gl.getAttribLocation(this.program,'vertexPosition’); For instance, I understand that is attached outside the regular mark-and-sweep as it’s a GL object, attached to a context (maybe, I’m not privy to the implementation detail, these are usually just indexes as OpenGL understands them.) There would be exceptions, like single-fire objects like some of the web audio API. > >> This, basically: >> >> 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.) > > 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. > >> 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. > > OK. We agree so far. ;) > >> System.gc() would be the same thing. > > 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, 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 :) Pointerlock? Missing in action in Safari. For some reason, it’s slow to start up in Safari, but fast in FF and Chrome, but runs as fast in all 3, but there’s weird slow downs in Edge. Why? Who knows. That’s the price you pay. We wouldn’t have a single API if we were worried about that. Not asking for miracles; I’m asking for best practice on an engine. We have an analog here — on FF, a call to JS_GC() is all I’d ask for. [>] Brian _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
