On 03/13/2016 02:50 PM, Brian Barnes wrote:
On Mar 13, 2016, at 5:22 PM, Steve Fink <[email protected]
<mailto:[email protected]>> wrote:
This is a good time to bring up the other half of my original email
because a number of other people have chimed in with their
experiences with GC when attempting to develop more time critical
applications without stutter.
I really don't think you want a System.gc() call for that. What if
you call that after you're placed in a background tab, when you're
sharing the JS heap with a latency-sensitive foreground tab? Do you
really want to stutter the foreground tab for (up to) a few seconds?
Probably not, in which case the name System.gc() would be a lie.
I think the closest you would want to go is to offer hints to the
runtime. AppIsIdleStartingNowForAtLeast(500)?
IDoNotMindIfYouDontCallMeAgainFor(500)? (units are milliseconds). The
runtime can ignore it, or it can schedule an up-to-500ms incremental
GC slice, or whatever. That does not negate all of the issues Boris
was referring to, but IMHO it's a reasonable middle ground. We could
double-check it against pending timers or whatever.
System.gc() would have a callback; it would block until you regained
front status. That has some edge cases, but that’s something the
programmer would have to be aware of.
That was one example off the top of my head, which as you say can be
resolved if specifically addressed, and it still spawns edge cases.
There are sure to be many other problematic cases, and if you don't
handle all of them and their edge cases, then by implementing this we
are likely to paint ourselves into a corner -- you use it, everything
works fine until some other engine or user code optimization exposes
edge case X, but we can't fix that without breaking other users.
Not to mention that your specific workaround make GC observable, which
is an information leak making it possible to depend on GC scheduling,
which means making it possible to prevent engines' GC behavior from
changing.
In a specific embedding, what you're asking for is reasonable. I would
even go so far as saying that it might be good to reserve some chunk of
the namespace for hints or whatever (though perhaps Symbols make that
unnecessary.) If you are in an embedding that ships with a specific
version of a JS engine and doesn't need to share anything with other
things running JS, then it's fine to give user control over GC
scheduling, manipulate bare pointers, suppress type guards and operate
blindly on known types, generate machine code and run it, or whatever
else your application desires. But you're not going to get stuff like
that added to the spec for a language that needs to work in environments
with evolving JS engines running frozen shipped JS code or hostile code
sharing the same VM.
For all I know, es *may* start carving out parts of the spec that only
apply to "privileged contexts". I haven't been following it, but I could
imagine such a thing might be needed for SharedArrayBuffers and related
things. Heck, browsers have fullscreen modes, where I am free to mock up
your bank site's login page. But privileged stuff will very careful
handling to avoid hobbling ourselves with long-term
evolution/compatibility hazards and security problems.
The second part of this is native primitive types; having int/etc
means they can be passed by value which means these checks are
easier, but that’s probably something others have argued back and
forth for a long time :)
The dynamic profiling can figure out whether *in practice* particular
values are always int/etc while certain code executes, and compile
with that assumption. Declaring types can give that a head start, but
it'll still need to be double-checked when not easily statically
provable, and may end up just wasting time prematurely compiling code
with incorrect assumptions. JS right now is simply too dynamic to
prevent all possibility of strange things happening to seemingly
simple values. Besides, just observing the types seems to work pretty
well in practice. The main benefit of type declarations would be in
preventing errors via type checking, IMO.
Right, I understand all that, and to me, that would be part of
compilation. If a lower level pass through, or if a number of them,
is required, than that’ll will have to be done (before types.) If
there are levels before full compilation that can be skipped, then
that’s all this hint would ask for.
I have to apologize because I think people keep thinking I’m asking
for something that solves a specific problem in a specific way; what
I’m asking for is something that is more contactually simpler … “X
always gets the most aggressive compilation”. If that takes multiple
slow passes, then that’s fine. It’s not “NO slow passes” it’s “always
strive to maximize speed over start up time."
Well, "the most aggressive compilation" is undecidable in general, since
you can't predict the future to know if some future execution won't
invalidate this or that constraint. But sure, I think we're basically
agreeing, except that I insist it'll only work if you phrase things as
hints about things you know about your code (such as that startup is now
done and the honeymoon period for latency is over), *not* as directives
to do this or that. Engines have to be free to ignore anything you say,
and to choose the right thing to do in response to a hint (which may be
very different from what you'd guess from the outside), and even then we
can shoot ourselves in the foot if anyone starts depending on things.
I can tell you in my case (http://www.klinksoftware.com/ws/) there
isn’t anything that won’t benefit from every class (and it’s all
classes) being compiled.
I have not looked at your case, so I can't speak to that. But I can tell
you that most of the time, when I dig into a particular chunk of JS
code, it ends up executing very differently from how you'd expect.
"Compiling everything" is rarely the globally optimal solution, although
in your case the downsides may be irrelevant to you. (Slower startup,
higher memory usage.)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
