Hi,
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
My name is Wei Wu and I would like to participate in Mozilla during GSoC
2013 as a student. I have been studying IonMonkey for several days, but I
haven't found any related ideas about it on Mozilla's idea list
pages[1][2].
[1]: https://wiki.mozilla.org/Community:SummerOfCode13
[2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
Based on [2], the deadline for GSoC projects seems to be already passed
(March 29th). You can still ask Gerv & Florian as suggested on [1].
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> The following are some ideas I'm interested in and I want to
> know your opinions/comments:
>
> 1. Save Type Information for Continuous Optimizations.
> SpiderMonkey interprets JavaScript bytecodes in the first place and
> collects type information. IonMonkey will not be called until the type
> information is stable. If we save type information on disks and reuse it
> next time, it will shorten the interpreting time and enable further
> optimizations.
> ( This idea comes from [3]. )
They are multiple issues related to this project, and the Type Inference is
a hairy part of SpiderMonkey. Some of the issues are that code can be
generated through an eval function call, the filesystem cannot be considered
as reliable in terms of latency, and Type Inference might shrink at some
point which can improve performances.
Notice that riadh [3] investigated the performance benefit of doing some
caching on the bytecode. And proved my assumptions to be incorrect. One
aspect which might be interesting would be to add some lazy-loading of the
bytecode. As you might know most of the JavaScript code which is downloaded
is rarely executed, it might be interesting to see if we can optimize such
cases especially for saving memory in b2g.
> 3. Improve the JIT Inspector.
> JIT Inspector is a very useful tool for profiling. But its UI is relatively
> simple and the interpretation of the results is not easy for beginners. I
> can improve the UI to make it more user-friendly. Also, I am glad to
> implement some features for it, e.g. saving results in a file, etc.
The JIT Inspector is some-kind of internal tool which is not a priority, and
is frequently broken, as we add/remove/modify JITs.
I think what would be even more interesting on this axes would be to provide
an API (possibly integrated with the dev tools) which somehow return a list
of possible enhancement based on the internal counters and on the
compilation choices (polymorphism, type). Using this interface with
different verbosity level can result in the same out-come as what the
JIT-Inspector is reporting.
The main reason why the JIT-Inspector does not have a lot of love lately is
because its output is extremely tie to the internal representation, and
changes to the internal representation / process need to be instrumented as
the changes are made, which is not a priority.
On Wed 17 Apr 2013 09:43:47 AM PDT, Luke Wagner wrote:
> Hi Wei Wu,
>
> Thank you for your interest! Bug 854627 may be a pretty frustrating GSoC
project and first bug on our JS engine in general; it'll mostly require a
significant amount of refactoring that depends on knowledge of how the JS
engine works. Something in IonMonkey may be more appropriate; perhaps
Nicolas has some thoughts on this?
>
> Cheers,
> Luke
They are multiple projects which might be of interest for IonMonkey, such as:
- Clarifying our heuristics, to be able to make guesses while we are
compiling in IonMonkey, and recompile without the guarded assumptions if the
bailout paths are too costly. Our current view is mostly black & white and
only one bad use case can destroy the performances. We need to introduce
some gray view, saying that we are compiling for the likely sub-set and
accept bailouts as part of the normal lifetime of a script. As of today,
IonMonkey is too much like a normal compiler, we should make it an
assumption based compiler.
- Adding resume operations, such as an instruction can be moved to a later
point in the control flow. One of the problem inherent to the imprecise
typing that we have with JavaScript is that any code can break one of our
assumption and cause an invalidation. In case of bailout, we need to resume
the execution in in the interpreter, and thus we need to have executed
everything before. With resume operations, we can delay an operation to a
point where it is needed and add resume operations if we bailout before the
computation. To give a support to what I attempt to explain:
function f() {
var x = 0;
for (var i = 0; i < 1000; i++) {
x = … pure & inlined computation …(i);
if (… unlikely condition independent of x …) {
… use x …
break;
}
}
}
In this function, x computation is worth moving under the if branch.
This optimization is a blocker for any optimization which can be done with
the escape analysis.
- Adding profile guided optimization, the idea would be to profile which
branches are used and to prune branches which are unused, either while
generating the MIR Graph, or as a second optimization phase working on the
graph. A trivial way of doing so can just look at the jump target which
have been visited so far. A more clever one might register the transition
and use Markov chain to determine relations between branches, and duplicate
a sub-part of the graph to improve constant propagation and the range
analysis. Before doing anything fancy like the more-clever case we still
need to check that this is worth it and see the benefit of other
optimizations if we fold the graph.
Other case of smaller projects might be:
- Improving our Alias Analysis to take advantage of the type set (this might
help a lot kraken benchmarks, by factoring out array accesses).
- Improve dummy functions used for asm.js boundaries. Asm.js needs to
communicate with the DOM, and to do so it need some trampoline functions
which are used as an interface with the DOM API. Such trampolines might
transform typed arrays into strings or objects and serialize the result back
into typed arrays.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
