As far as I know, any system that didn’t do GC would need to be compiled; you’d have to track the objects with some kind of graph (like ARC) and deal with it that way. Compiling isn’t something you’d probably want to always do to javascript, especially as so much of it runs once and only once — you’d only compile after that. Which is why the future of a non gc system seems unlikely at this point.
System APIs are full of potential noops, graphic and disk systems have flushes and cache empties which might or might not do anything, based on the architecture of the system. This isn’t really anything programmers haven’t seen before. So a gc() that does nothing on a system with some sort of advanced memory management is fine; the problem is already solved, the gc is a no-op. But you can’t not solve problems now because of future events. As for being a de-optimization hazard, that’s certain a problem, but we shouldn’t disallow the usage of something because programmers are bad. We should teach programmers better. It could certainly happen on a callback, too, which I think is perfectly fine. As far as I know, most all gcs I’ve seen have different modes, small gcs, and large gcs. A callback would solve any concurrency problems, and probably make a better system. It leaves the implementations details out of the hands of the user code. [>] Brian > On Mar 12, 2016, at 7:45 PM, liorean <[email protected]> wrote: > >> Am 12.03.2016 um 07:27 schrieb Brian Barnes: >>> Request 1: Add a System module, and one call I need System.gc(); >>> >>> Why: My game works in two parts; one part creates all the content, and >>> then the second part plays it. In the second part, I do as much as I >>> can to precreate/re-use any objects or arrays I need, to reduce GC. On >>> the creation part, I don’t as much. So being able to force a GC at a >>> point helps me, because it stops the creation part from forcing a pause >>> in the game part. > > On 13 March 2016 at 01:05, Christian Mayer <[email protected]> wrote: >> On my user-should-experience-no-pause kind of application I'd also love >> to have the possibility to tell the engine to do a GC *now* as it's a >> good time point to do it. > > Problem with that is that you're making assumptions that are not > guaranteed about the engine already: > - That it uses a garbage collector. (I believe it's not entirely > implausible to compile JS to a manually memory managing engine > internal code, and I know that there are engines that never return any > memory while still running, though they might reuse unreachables.) > - That the eventual garbage collector has certain properties such as > pausing execution. > - That eventual garbage collector isn't incremental and running very > small slices practically all the time, which might make precise user > code control over it a deoptimisation hazard. > - That dead object detection, garbage collection, memory compaction > and resource handling is dealt with in the ways of a typical > conservative mark & sweep fashion. > - That ECMAScript actually specifies any of this. Neither garbage > collection, nor memory handling strategies are a part of the spec. In > fact, the word "memory" is only mentioned three places in the entire > ECMAScript 2015 spec, and "garbage collection" only once. > > -- > David "liorean" Andersson > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
