Hi Nicolas, Thank you for your patience! I'm very happy to receive your reply!
On Fri, Apr 19, 2013 at 10:01 AM, Nicolas B. Pierron < [email protected]> wrote: > 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<https://wiki.mozilla.org/Community:SummerOfCode13> >> [2]: >> https://wiki.mozilla.org/**Community:SummerOfCode13:**Brainstorming<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]. No problem, I as a student can submit new ideas before May 3rd. > > > 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. > Hmm, I agree that finishing type inference related projects may beyond the complexity of a GSoC project. > > 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. I found a bug (#825268 <https://bugzilla.mozilla.org/show_bug.cgi?id=825268>) that may related to this project. According to the description of that bug I realized that my understanding of the term 'heuristics' is relatively naive (the strategy used by an optimization algorithm to modify the intermediate representation is based on a few expressions calculated from the structure of source codes.) and I think the heuristics you mentioned are more generic than that. If I understand correctly, 'compiling for the the likely sub-set' means that we can compile multiple versions for a method and execute one of them based on which one's assumptions are satisfied. for example: function g(x){ ...use x... } function f(){ for (var i = 0; i < 10000; i++){ if (i % 1000){ g(i); }else{ g('string'); } } } Currently IonMonkey compiles g(x) with the guard "assert(typeof x === int)" and the jit code will be invalidated periodically. If g(x) can be compiled with the assumption "assert(typeof x in {int,string}" then the bailouts would be avoided. Am I right? > - 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. > > I'm interested in this idea and I'm willing to implement it. A simple and fast algorithm may be a good choice for GSoC, while the advanced methods require more investigation. I haven't found any branch profiling code in the interpreter so the instrumenting mechanism must be finished first, or we can leverage baseline compiler to generate self-instrumented jit code. Profiling data can be saved separately or in MIR nodes as an annotation. In the second case more other passes may benefit from it easily. Two bugs (#410994 <https://bugzilla.mozilla.org/show_bug.cgi?id=410994>, # 419344 <https://bugzilla.mozilla.org/show_bug.cgi?id=419344> ) have mentioned PGO but may be irrelevant with this idea. > 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). > My knowledge about Alias Analysis is limited; I know the principles and have read [4] <http://dl.acm.org/citation.cfm?id=277670> one year ago. I am not sure how type sets can help subsequent optimizations. Would you please provide me some more information(wiki, blogs, or papers) about it? [4]: http://dl.acm.org/citation.cfm?id=277670 > > - 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. > > I haven't read OdinMonkey's code yet, but I will look into it next week. Speeding up asm.js on ARM is one of my interests. > -- > Nicolas B. Pierron > > ______________________________**_________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@**lists.mozilla.org<[email protected]> > https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals> > -- 吴伟(Wei Wu) _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
