Re: "Super" hoisting

If we ever get access to GC primitives, I would like to make sure that it is minimally specified. An example of this is that in the JVM standard, `java.lang.System.gc()`'s behavior is completely implementation-defined. Matter of fact, IIRC the standard explicitly mentions that doing nothing is conf

Re: "Super" hoisting

> my stuff, you'll see it's pretty free from GC, but that's because I pull a > lot of tricks, which make for messy and hard to understand code. Exactly, which is why standards around GC might help; to prevent the messy brittle code that developers making graphically intense apps will end up writi

Re: "Super" hoisting

It much easier to solve then that, just make a,b,c globals in the class constructor (again, let's consider than objects, not primitives.) If you look at my stuff, you'll see it's pretty free from GC, but that's because I pull a lot of tricks, which make for messy and hard to understand code.

Re: "Super" hoisting

Maybe now that realtime graphically-intensive applications in the web are becoming a thing, there needs to be some sort of standardization on GC so that devs can make meaningful decisions on GC (rather than guessing how to best optimize for different engines and often writing ugly code because of i

Re: "Super" hoisting

I think the original problem that caused this discussion with GC could be solved with just a weak map: ``` // Original class thing { doSomething(x, y) { let a = x + y; let b = ay; let c = bx; return (c); } } // With a weak map const wm = new WeakMap() clas

Re: "Super" hoisting

> On May 13, 2016, at 12:13 PM, /#!/JoePea wrote: > > > Or "Cython in Javascript". I think your needs can be satisfied by C/C++ > > addons in Node.js or WebAssembly in browser > > But we want to stay in JavaScript because we like the language. Plus, writing > a framework in JavaScript has the

Re: "Super" hoisting

> On May 13, 2016, at 12:23 PM, Herby Vojčík wrote: > > It's different. Does _allocation_ or _GC_ eats the performance? That’s a good question. It’d be hard to tease out that data for runs of the source, but I suspect it’s GC, because it’s a pause, not an overall slowdown. And over-all paus

Re: "Super" hoisting

On Fri, May 13, 2016 at 4:19 PM, Herby Vojčík wrote: > > > Nicolas B. Pierron wrote: >> >> I do not understand how having local variable should change any GC >> pattern unless you are creating them in the for-loop body. > > > If I understand correctly, the problem is in not reusing the objects. If

Re: "Super" hoisting

On Fri, May 13, 2016 at 4:13 PM, /#!/JoePea wrote: >> I do not understand how having local variable should change any GC pattern >> unless you are creating them in the for-loop body. > > Having locals in a for-loop is the same as having locals in a function that > gets called at 60fps in an animat

Re: "Super" hoisting

I can only tell you what I’ve tested and observed, not sure of the inner workings of any javascript engine. Current alpha of my project is here: http://www.klinksoftware.com/ws/ Recommend latest firefox or chrome. Github link for the code is there. This is

Re: "Super" hoisting

Nicolas B. Pierron wrote: I do not understand how having local variable should change any GC pattern unless you are creating them in the for-loop body. If I understand correctly, the problem is in not reusing the objects. If you do `var x = new X()` in every call of the method, GC should tak

Re: "Super" hoisting

> var x = XPool.get(); I think Brian is saying that local vars are GCed, so that solution doesn't work (creating many local variables at 60fps) > Or "Cython in Javascript". I think your needs can be satisfied by C/C++ addons in Node.js or WebAssembly in browser But we want to stay in JavaScript

Re: "Super" hoisting

> On May 13, 2016, at 11:09 AM, Herby Vojčík wrote: > > > > Brian Barnes wrote: >> It could be, but there is a difference between: >> >> var x; >> >> and: >> >> this.x > > You should probably do `var x = XPool.get();` and at the end `XPool.put(x);` > and do `XPool`s for every possible X ty

Re: "Super" hoisting

Certainly, I’d love webassembly, but as of now, it’s not something that’s part of the spec, or something that I can use right now, and I also want to see how far I can push the language as an experiment. I think there is a place for improving the language as is; it’s surprising how far javascri

Re: "Super" hoisting

I do not understand how having local variable should change any GC pattern unless you are creating them in the for-loop body. Even though, Scalar Replacement optimizations (which are implemented in all engine?) should be able to remove these allocations once the optimizing JIT is reached, unless th

Re: "Super" hoisting

It's recurring theme - special syntax to allow/force engines to optimize some code pattern. What do you want is in fact some kind of C. Or "Cython in Javascript". I think your needs can be satisfied by C/C++ addons in Node.js or WebAssembly in browser - it's better to use proper tool rather than t

Re: "Super" hoisting

Brian Barnes wrote: It could be, but there is a difference between: var x; and: this.x You should probably do `var x = XPool.get();` and at the end `XPool.put(x);` and do `XPool`s for every possible X type which you want to not GC. And then happily use local variable, as it should be. If

Re: "Super" hoisting

It could be, but there is a difference between: var x; and: this.x Because you’ll get leakage from the last run, so it would probably be something that would need to be hinted, unless the engine was smart enough to reset everything it hoisted (which is doable) but not optimal, as you might al

Re: "Super" hoisting

Sounds like a potential JS engine optimization, rather than a language feature per se. > On May 12, 2016, at 1:53 PM, Brian Barnes wrote: > > Not by my testing, at least. > > My original example is a simple one to explain what the procedure is. Here’s > a more complex example, from my code,

Re: "Super" hoisting

Not by my testing, at least. My original example is a simple one to explain what the procedure is. Here’s a more complex example, from my code, from my mesh classes. This function updates the vertices in the mesh based on the position of the bones of a skeleton, it gets called every frame for

Re: "Super" hoisting

> On May 12, 2016, at 9:39 AM, Brian Barnes wrote: > > ... > If I call doSomething a lot of times, I get a lot of objects to be tracked > and GC’d. Yes, I can rewrite that code to obviously eliminate them, but > pretend there is actually something interesting happening here that requires > t

Re: "Super" hoisting

Formatted the code so that it can be read: ``` class thing { constructor {} doSomething(x, y) { let a = x + y; let b = ay; let c = bx; return (c); } } class thing { constructor { let _doSomething_a = null; let _doSomething_b = null;

"Super" hoisting

Another idea I had, something I do all the time but would be interesting to see in a syntactical sugar approach. Again, almost all this is because I (and many others) are writing real time, GC-sensitive applications (in my case a auto-generated first person shooter, every bitmap, every surface,