That sounds like a good idea, being able to hint to the browser when
is a good point to GC, and also when to avoid GC if possible.

Idea: Maybe we have an animation that last 500 ms. Before the
animation, we can call `System.preventGC()`, and the browser can
prevent GC for as long as possible, but will still do it if absolutely
necessary (i.e. if memory needs to be freed to allocate more). Then,
after that animation finishes, a call to `System.attemptGC()` could
signal the browser to go ahead if it hasn't already. This ability to
hint could be very handy. It's like requestAnimationFrame: it is used
to hint at the browser that some code should be run between frames,
but it doesn't guarantee that the code won't cause jitter if the code
exceeds time limits, it's just a hint. We could use some way to hint
at GC too.

Another Idea: what about a directive like "use scope-gc", that when
placed in a function GCs the function's scope as soon as that scope is
gone (as soon as the function has returned)? That would guarantee that
GC happens after functions complete, on a per-function basis if
included in every function, and it would encourage re-use of allocated
things like Florian mentioned for things like animation. Also, the
function's return value wouldn't be returned until GC of the
function's scope is complete. This would allow GC to be timed inside
animation loops with performance.now(). It would be a whole new GC
implementation only used in functions that have the directive. It's
like telling the browser "hey, I'm done with this scope, GC it right
now before returning the function's return value". This would mean
that the style of programming used in a function would be directly
related to the amount of GC time for that function. I don't know the
implementation details of current GC, but I can completely imagine
that it's possible, and that it might be useful due to the fact that
GC si guaranteed and we know exactly when it happens (at the end of
each function execution). The overall effect, if "use scope-gc" is
used in every single function of an app, would be that GC will be
event spread across all function calls, instead of at arbitrary times
between many function calls.

Maybe a combination of hinting APIs, and that scope-gc directive,
could lead to better overall control for important things like
animation. For other things (where the user doesn't notice) it doesn't
really matter so much. Something so simple as "jank" is what causes a
user to dislike an app compared to another without jank, and hence the
"native" vs "web" (with "native" winning) discussions.

TLDR: If there's absolutely anything that we can do to improve
animation performance, please, let's do it!

On Sun, Mar 13, 2016 at 7:43 PM, Brian Barnes <gga...@charter.net> wrote:
> Boris, I think we’re going in a couple circles here, so let’s not waste 
> anymore time (though it’s a fascinating discussion.)  I think you’re 
> complaints come down to:
>
> 1. Potential mis-use of API could make things slower
> 2. People assuming things could freeze behavior
> 3. People will assume behavior outside of the spec
> 4. What does GC mean?  People will assume everything.
>
> Which I can understand your position, though I disagree, but that’s more 
> philosophical, and not something we can probably debate down.  And I 
> apologize if I mis-represent your argument here, but that’s the gist I get.
>
> So let’s move it a little.  How about this concept:
>
> A call that hints that next time control is released from a script, that it 
> triggers whatever the next type of GC, whatever it is, of any of the methods, 
> that would get triggered close to this time.  So:
>
> // lots of code
> System.stageMaybeGC();
> setTimeout(blech,X);  // not necessarily this, but just anything that will 
> release control
>
> blech() {}      // maybe you got a GC
>
> Now, it might be a minor GC, but I can stage these after every complex 
> operation that makes a lot of objects.  At this point, I’m not interrupting 
> or pausing or doing GCs the system wouldn’t do in it’s normal operation.  The 
> system can also say “hey, a GC here would be bad, I’m not going to do it” and 
> skip it.  Or the system can go, “hey, I do have a lot of stuff, and the 
> programmer knows this is a good time."
>
> Control would be required to be released.  It’s maybe, and whatever it does 
> is what the engine decides to do.  And you can’t misuse it because it forces 
> you to release control, so nobody can use it in a tight loop (well, they 
> could, but it would be super, duper dumb.)
>
> Thoughts?
>
> [>] Brian
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to