Dlteam-list Février 2013

dlteam-list@iro.umontreal.ca

7 participants
18 discussions

Démarrer une nNouvelle discussion

DConf 2013
by chevalma＠iro.umontreal.ca 12 Fév '13

12 Fév '13

http://erdani.com/d/conf/talks/chevalier-boisvert.html

1 0

Fwd: [resolve_2013] Accepted paper #3 "Harnessing Performance for Flexibility..."
by Erick Lavoie 08 Fév '13

08 Fév '13

Commentaires sur l'article RESoLVE. Erick -------- Message original -------- Sujet: [resolve_2013] Accepted paper #3 "Harnessing Performance for Flexibility..." Date : Fri, 01 Feb 2013 03:57:07 +0000 De : Robert.Watson(a)cl.cam.ac.uk Pour : Erick Lavoie <acm(a)ericklavoie.com> Copie à : Robert Watson <Robert.Watson(a)cl.cam.ac.uk> Dear Erick Lavoie, The Runtime Environments, Systems, Layering and Virtualized Environments (resolve_2013) program committee is delighted to inform you that your paper #3 has been accepted for presentation at the workshop. We look forward to seeing you in Houston. Title: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity Authors: Erick Lavoie (Université de Montréal) Bruno Dufour (Université de Montréal) Marc Feeley (Université de Montréal) Paper site: http://svr-hotcrp.cl.cam.ac.uk/hotcrp/resolve_2013/paper.php/3?cap=03aKUmFs… Your paper was one of 6 accepted out of 7 submissions. Congratulations! Reviews and comments on your paper are appended to this email. The submissions site also has the paper's reviews and comments, as well as more information about review scores. Please read the reviews and comments and revise your paper and presentation accordingly. Contact the site administrator, Robert Watson <Robert.Watson(a)cl.cam.ac.uk>, with any questions or concerns. - resolve_2013 Submissions =========================================================================== resolve_2013 Review #3A Updated Monday 21 Jan 2013 12:04:51am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== The paper describes instrumentation of JavaScript programs by, in effect, building a metacircular VM implementation. ===== Comments for author ===== I am OK accepting this paper for the workshop -- it is on-topic, and I expect people will be interested in JavaScript instrumentation and debugging. That said, I do not think the presentation of the work is very effective, and (as the paper says) distinction with source-to-source instrumentation is relatively slight. In terms of presentation, I would suggest adding an early running example. In general it is better to start with a simple example that the reasder can understand, and then to move on to the general case. The current paper introduces a lot of abstract detail before getting on to a relatively complex example. I would add (1) a diagram showing the layers and components of the system, (2) a worked example of a single method call and the associated caches. Detailed comments: * "regular semantics of JS", suggest avoiding the word "regular" (it can mean "ordinary", or "orthogonal", or "at fixed periods", so is often ambiguous). * Section 2, I was unclear what level the call, get, send operations are working at -- and if these are actual implementations, or just meant as pseudo-code. Again, I think having a simple example before these details would help explain this better. * Memoized methods -- I was lost at this point. I was unsure if this was a feature of the input JS programs, or an implenentation technique being used by the VM. * The paper should be more candid about perf in the abstract and intro: it is 2x slower than an interpreter, and much slower than a JIT implementation (50x). It would be interesting to look in more detail at the source of the perf costs -- are there particular kinds of instrumentation that are costly? Is there evidence that a smarter underlying VM could strip away un-used instrumentation? =========================================================================== resolve_2013 Review #3B Updated Friday 25 Jan 2013 12:18:29pm UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 4. Accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper discusses the creation of a metacircular JavaScript virtual machine as a means of instrumenting JavaScript code without having to maintain an instrumentation framework alongside a complex performance oriented JIT VM. The authors propose using message sending semantics as the means of building this VM, which, when executed on top of a state-of-the-art JIT based javascript VM, provides acceptable performance in comparison to a modern interpreter based JavaScript VM. ===== Comments for author ===== This is an on-topic paper which should be of interest to attendees of the RESoLVE workshop. I think the message sending based techniques used to build the metacircular VM is interesting, as are the insights that they can perform code cacheing using the dynamically specializable abilities of Javascript. However, the paper's presentation makes this work difficult to follow. The paper dives right into the low-level techniques used to build the VM, with no real discussion of how these techniques relate to the "compilation" of user-level code. Then, in section 4 a compilation example is presented, but this example is quite complex and it's difficult to follow how the previously discussed techniques are used in it. I think the paper could be improved by having a simple running example which permeates the implementation discussions to help describe them, then put all these running examples together in Section 4 to show how the approaches work together. I also struggled to clearly understand when and where the optimizations to the code cache were happening. For example, how does the __memoization__ tag interact with the virtual machine. This might be clearer if the authors presented the transformations for a simple compilation example and described where the VM interacts with the source-to-source translated user code in order to carry out these transformations. Also, the use of the word memoization seemed a bit misleading, since it would imply that the function's result is memoized meaning the function doesn't need to be called at all, whereas what is being discussed in the paper is the memorization of the message send operation, while the user-function is still being called. Finally, it would have been interesting to see how instrumentation is inserted into the compiled code - there is very little information given on the implementation of Pn-spl or Pn-fast presented in the evaluation. I would have been interested to discover how the two approaches differ in more detail as well as some discussion on how tied Pn-fast is to the current VM implementation, and whether changes in the VMs implementation would require significant work to ensure the instrumentation features still worked correctly. Overall though, I think this paper would be a worthwhile addition to the RESoLVE workshop. =========================================================================== resolve_2013 Review #3C Updated Sunday 27 Jan 2013 4:59:40am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 2. Weak reject Reviewer expertise: 2. Some familiarity ===== Paper summary ===== This paper describes the a Javascript instrumentation framework that relies on meta-circular evaluation to simplify its construction. The paper describes a few optimizations that reduce the overhead of instrumentation. It finally describes preliminary performance results comparing the new Javascript VM (Photon) with a interpreter (SpiderMonkey) and a JIT-based (V8) VM. ===== Comments for author ===== This was a difficult paper to read. Perhaps I would be more positive about the work if I had an easier time grasping some of the concepts presented. Unfortunately, I still have several basic questions that I was unable to answer. So, more than anything, I'd encourage the authors to improve the presentation of the work so that readers can fully understand its technical value. A few suggestions: * The Introduction does not clearly describe what problem this work addresses, and how it proposes to do so. It is important to describe what type of instrumentation this work attempts to perform (and why). I did not find this anywhere in the paper. Furthermore, why is it important to make instrumentation a separate entity (is instrumentation targeted to writers of Javascript VMs or applications writers?). Certain phrases, such as, "Our approach relies on an object representation based on proxies that exploit a previously unexploited constraint: the prototype chain of the proxies mirrors the prototype chain of the objects" are difficult to begin to parse without the context of the remainder of the paper. Even then, I find it challenging. * Closed-world vs Open-world assumptions. First, please define these terms more carefully in your context. The terms I knew were from the area of formal logic, and it is not clear how they apply in your context. More importantly, why does it matter which type of system you build? Do these provide the same functionality to your target instrumentation? * A premise in this work is that meta-circular evaluation will make building VMs with instrumentation easier. Do you believe that new Narcissus VM, also based on meta-circular evaluation, will make instrumentation JS code easier? Or is it simply a function that the VM proposed in this work is small and highly customized to provide instrumentation hooks? * Because I did not understand the introductory questions above, I was left wondering if going through the trouble of building a new VM based on multi-circular evaluation is worth the trouble. For example, there are numerous projects that perform compilation to Javascript (see: http://altjs.org/). Also, given that I'm not sure about the level of instrumentation desired, it seemed that this work was largely replicating the concepts of Aspect-Oriented Programming, where the instrumentation is designed as aspects for specific JS objects. And a simple plugin to JQuery allows one to extend JS object behavior using AOP (which just a couple hundred lines of JS code; also the overhead of this is expected to be minimal and only dependent on the instrumentation itself): https://code.google.com/p/jquery-aop/ * About the messaging. Please first explain, at a high-level, why you decided to base your system on messaging, and how it is used in your system. Second 2 started discussing messaging as if I had knowledge of its purpose in the overall system design. As a consequence, all of Section 2 was very confusing. What's the difference between messages and a simple method invocation? Why is it necessary to wrap method calls as messages? * It seems that a fundamental Javascript feature that this work leverages is the ability to evaluate code at run-time (eval() function). It would be helpful to clearly explain this in the paper (maybe in a section describing the high-level concepts of Photon, before describing the messaging layer, for example). * In the experimental section, we see that Photon reduces the performance of V8 by 200x. This is quite significant, and would make be weary to use such a heavy-weight instrumentation framework. For example, for identifying hot-spots, it is not clear that this instrumentation framework would not significantly alter the performance behavior of execution, making any conclusions from this framework unreliable. * A minor point, also in the experimental section, one data point stuck out. In Table 9, Pn-fast receives a 25% performance boost over Pn for DeltaBlue. The only justification is that these are "natural variations of results". I find this to be a non-trivial variation in execution, and would urge future versions of this work to attempt to improve (or quantify) the statistical significance of the results. =========================================================================== resolve_2013 Review #3D Updated Monday 28 Jan 2013 10:04:57am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 2. Some familiarity ===== Paper summary ===== The authors use a hierarchy of proxy objects to "wrap" an application's own object hierarchy and use this to instrument the application. The same wrapping mechanism is used to also support inline-caching optimizations to reduce the overhead of instrumentation. In all cases, the approach exploits the proxy feature which will be coming in future versions of JavaScript. ===== Comments for author ===== What if application already uses proxy objects? How are these instrumented by the additional hooks? What are the (circularity) issues here and how do different attempts at instrumentation compose? Some questions about the performance section: + explain what the baseline is better at the start of section 6 (indirection through proxies, on V8) + what is the impact of conservative assumptions for simpler invalidation of caches, etc.? + in tables 7 and 9: what does "v8 score" mean? isn't this geo mean? + the tables would read better as graphs Have the authors looked at frameworks like the Spring (aspect-oriented) framework that does something like this in a less general way to build large Java applications? Minor comments: Introduction: "running of the VM" --> "running on the VM" Table 3: "Lookup method then call." --> "Look up method, then call." Table 4: "has his method being updated" --> "has its method updated" Section 3.2: "requires to specialize" --> "requires us to specialize" Section 4: "syntax tree nodes as preserved." --> "syntax tree nodes are preserved." Section 5: "is in most cases, is also" --> ", in most cases, is also" Section 6: "they have the same name" --> "they have the same name." "should the prototype of an object changes" --> "should the prototype of an object change" =========================================================================== resolve_2013 Review #3E Updated Wednesday 30 Jan 2013 8:12:23pm UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper focuses on the low-level details of instrumenting OO accessors and method calls in Javascript by transforming programs into a proxy-based message-sending representation. The paper gives details of the model, the code transformation required including consideration of various corner cases, and an empirical performance analysis. The work exists in a vacuum - in that little motivation is given for instrumenting Javascript programs. Further there is only limited discussion (in opening paragraphs of sec 1, closing paras of sec 5) about alternative approaches to Javascript instrumentation. In summary - a detailed technical paper, which could be of interest to RESOLVE workshop attendees. Hence weak accept. ===== Comments for author ===== Generally clear where the paper is going - although given the amount of technical details sometimes it is difficult to see the wood for the trees. I would appreciate more high-level motivation personally. Sect 5.5 - related work - make this a new top-level section, rather than a subsection. You show how this proxy-based technique can be useful for whole-program instrumentation - e.g. for counting number of method calls etc. Could it also be a good approach to dynamic aspect weaving for prototype-based languages?

1 0

Rencontre à 10h30
by Marc Feeley 08 Fév '13

08 Fév '13

N'oubliez pas la rencontre ce matin à 10h30... Marc

1 0

Compte-Rendu #4
by chevalma＠iro.umontreal.ca 07 Fév '13

07 Fév '13

Dans les 24 dernières heures, j'ai eu des rencontres avec Luke (JS team), Shu, Étienne, Ariya Hidayat (du parseur JS Esprima) et Jandem/Djvj qui travaillent sur le baseline JIT. J'ai une plus grande compréhension de l'analyse de types de Mozilla et de leur compilateur(s). Ils veulent se débarasser de JaegerMonkey et le replacer par un JIT très simple qui compile directement leur bytecode, sans même faire d'allocation de registre, et utilise des inline caches (ICs). J'ai eu une bonne explication de comment leur ICs fonctionnent, en gros, c'est simplement une linked liste de petits blocs de code machine qui testent des conditions (genre type des objets). Ils planifient utiliser les ICs pour faire du type feedback. Ils planifient éventuellement remplacer leur inteprète bytecode par quelque chose d'encore plus simple: un AST walker. Dans les mots de Terrence ici: "interpreter performance doesn't matter at all". Leur interprète ne servira qu'à exécuter le code qui ne roule que quelques fois. IonMonkey sera en mesure de faire des bailouts vers leur JIT baseline (pour l'instant, Ion bail vers l'interprète). Shu m'as fait un petit exposé sur l'analyse de types. Il y as certains aspects dont je pourrais m'inspirer, mais je ne sait pas si je peux améliorer beaucoup sur leur design. J'ai parlé de mes idées sur le tracing à Shu. Il semblait très sceptique au départ, mais plus intéressé vers la fin. Il me recommande de ne pas référer à mon approche comme un "tracing JIT" puisque ça n'en est pas un dans le sens classique, et de faire une recherche en littérature pour voir si je peux trouver des choses similaires. Ce que j'ai trouvé de plus proche, c'est le "region-based compilation", venant du monde HPC. L'idée en gros: découper les programmes en unités de compilation autres que les fonctions, et repousser les chemins d'exécution moins chaud en dehors de ces régions. Les articles originaux parlaient de faire ça soit basé sur de l'information de profilage, soit par analyse statique. Ceci a été appliqué à des compilateurs Java, mais pas aux langages dynamiques, à ce que je vois (dans le monde dynamique, la compilation de boucle par trace c'est tout ce que je trouve). Mon idée est similaire: essayer de faire grandir des extended basic blocks de façon dynamique et paresseuse pour éventuellement couvrir tous les chemins chauds. Faire grandir ces blocs en passant par les appels de fonction quand ça fait du sens, repousser le code mort ou "froid" hors des chemins critiques, dupliquer le code qui pourrait bénéficier de spécialisation. Shu semble croire que ce serait intéressant d'avoir des paramètres avec lesquels on peut jouer pour augmenter la croissance et le versionnement des blocs. Plusieurs métriques pourraient êtres produites pour différents paramètres. Peut-être serait-ce assez intéressant pour un premier article? (J'ai attaché ma discussion en ligne avec ceux qui travaillent sur le compilateur baseline, si ça vous intéresse)

2 1

Compte Rendu #3
by chevalma＠iro.umontreal.ca 06 Fév '13

06 Fév '13

Une mauvaise nouvelle: il semblerait qu'un sponsor de DConf demande un slot pour avoir une présentation. Andrei Alexandrescu est donc obligé de retirer son invitation pour le moment (à suivre). Ça continue bien pour les contacts professionnels cependant. Je rencontre quelqu'un presque tous les jours de la semaine, incluant samedi et dimanche prochains. Ce matin, j'ai eu une rencontre avec Luke Wagner et Michael Bebenita, avec le tracing comme sujet principal. Michael nous a parlé de sa thèse qui impliquait de la compilation de traces pour Java, et de comment il faisait pour résoudre le problème du trace explosion dans son compilateur. Il a fait face à quelques uns des mêmes problèmes que TraceMonkey. Son approche semble en effet éliminer le trace explosion, mais aussi plusieurs des avantages du trace compilation. Il donnait l'impression que dans le contexte d'un langage statique, le tracing n'en vaut pas vraiment la peine, parce que les gains à obtenir sont très petits. Michael soulève les mêmes doutes que Bruno à savoir si je peut créér avec Higgs un JIT suffisament rapide pour compétitionner avec FF et V8, préfèrerais que j'implante mon système par dessus IonMonkey. Personnellement, je ne crois pas cependant que d'implanter mon tracing JIT par dessus Ion soit vraiment une guarantie de battre les autres sur la performance. Cela risque de contraindre mon design et rendre les refactorings assez difficile si je dois ajuster le tir. Si ma thèse est: "j'ai un design de tracing JIT optimisant qui utilise de l'information de type, spécialise efficacement, et ne produit pas d'explosion de trace", le problème de savoir ce que je vais essayer de publier comme nombres demeure. J'ai eu comme idée que si on veut vraiment "battre" d'autres JITs sur la performance, il serait probablement assez facile de battre TraceMonkey (le tracing JIT abandonné de Mozilla). Les derniers articles publiés sur TM peignent une image très rose de celui-ci, mais il se trouve que, selon Luke et les autres, TM n'a absolument aucune solution au problème du trace explosion, la performance en terme d'i-cache misses est terrible, et le design comporte beaucoup de faiblesses. Toutes les benchmarks qui ne sont pas des boucles parfaites performent assez mal sur TM, qui, semble-t-il, retombe très souvent en mode interprété. Il est probablement aussi très possible de battre PyPy sur certains benchmarks. Selon les gens ici, PyPy prend 1-2 minutes à faire son "warmup". Ce serait amusant si on pouvait trouver un compilateur Python->JS et obtenir des meilleur temps qu'eux sur leurs benchmarks traduits à JS. Je n'exclue pas non plus la possibilité de battre IonMonkey sur des benchmarks bien choisis qui s'attaquent spécifiquement à ce qu'Ion optimise mal (programmation fonctionnelle, hauts niveaux d'abstraction... interprète métacirculaire écrit en JS *wink wink*). Expérience du jour: scores sur benchmarks V8 avec différentes configurations (higher is better): Options par défaut: 9194 IonMonkey seulement, allocateur de registre linear scan: 7722 IonMonkey seulement, allocateur de registre "stupide": 6100 IonMonkey seulement, sans loop invariant code motion: 7166 IonMonkey seulement, sans inlining: 6695 IonMonkey seulement: sans type inference: 333 JaegerMonkey seulement: 5002 Interprète seulement: 252 Surprenamment, l'inlining fait relativement peu de différence. Moins que le choix d'allocateur de registre, même sur earley-boyer (code Scheme compilé vers JS, plein de petites fonctions) le score est à peine changé. C'est probablement parce qu'Ion fait assez peu d'inlining. - Maxime

2 2

Re: [Dlteam-list] Compte Rendu #2
by chevalma＠iro.umontreal.ca 05 Fév '13

05 Fév '13

According to Luke, for typical web applications: ~76% of the code is dead A large percentage only runs for a short time (interpreted) An even smaller percentage runs in the baseline JIT An even even smaller percentage is optimized by IonMonkey IonMonkey is proportionately expensive, almost never runs, is almost never used on the web. According to Luke, it is used in parts of SunSpider, Octane and Kraken benchmark suites. - Maxime > Ce sont des bonnes nouvelles, et c'est intéressant de voir que leurs > compilos ne sont pas parfaits. J'aimerais bien comprendre un peu plus > pourquoi IonMonkey n'est presque pas utilisé. Est-ce que c'est vrai aussi > pour les benchmarks classiques (sunspider, etc)? On peut se demander > alors pourquoi ils se sont donnés la peine d'implanter un compilateur si > complexe. Donc, est-ce que je comprends bien que c'est le baseline JIT > qui roule le plus souvent (et qui est responsable de la performance de FF > sur les benchmarks)? > > Je te conseille de mettre la majorité de ton temps à continuer à explorer > leur code source pour pouvoir mieux comprendre leurs JITs. C'est ce qui > me semble le plus profitable pendant qu'ils sont à portée de main pour tes > questions. > > Marc > > > On 2013-02-04, at 8:39 PM, chevalma(a)iro.umontreal.ca wrote: > >> Je suis rentrée au bureau de Mozilla ce matin et j'ai un bureau dans le >> "js pit", avec les gens qui travaillent sur IonMonkey. Pour commencer, >> j'ai eu une discussion intéressante sur les moteurs JS de Mozilla avec >> Luke Wagner. On a discuté d'IonMonkey, de TraceMonkey et de leur analyse >> de typage. >> >> Il semble (encore une fois) que le TI de Mozilla soit très près de ma >> recherche. Cette fois, je ne m'en fait pas trop cependant. Je crois que >> mon travail est assez différent et publiable, et j'ai une longue liste >> de >> directions de recherche alternatives/complémentaires. >> >> Luke Wagner m'apprend aussi que, bien qu'IonMonkey soit assez >> sophistiqué, >> il y a beaucoup de choses qu'ils ne font pas: >> >> 1. Ils n'ont pas de contexte sur leur types d'objets. >> 2. Leur fonction map (Array.prototype.map) est une fonction C++ qui >> rappelle dans le code JS, de quoi faire froncer les sourcils de Marc. >> 3. Leur analyse de typage n'as pas de contexte sur les appels non plus. >> 4. Ils ne font aucune forme de versionnement de fonctions >> 5. Leur inlining est basé sur des heuristiques très ad-hoc, tweakés à la >> main >> 6. Leur assembleur ne fait aucune passe d'optimisation sur le code >> machine >> généré. Il n'y a pas non plus d'instruction selection. >> >> Selon Luke, IonMonkey ne roule presque jamais. C'est leur JIT le plus >> avancé, et c'est très rare que du code frappe le threshold qui le fait >> compiler par Ion, même s'il roule longtemps. Je trouve ceci plutôt >> étrange. Il existe un outil appellé JIT inspector, écrit par Brian >> Hackett, qui permet d'avoir certaines infos sur le travail des JITs. Je >> confirme que même sur des web apps qui font pas mal de CPU crunching, >> IonMonkey n'est pas utilisé. >> >> L'opinion de Luke sur TraceMonkey est tout aussi négative que celle de >> Shu. Il m'as donné plus de détails sur les hacks impliqués dans ce >> design. >> Il semble que la vérité est que Mozilla n'as jamais eu un tracing JIT >> "sérieux". C'était leur premier JIT, il a été poussé très vite du stage >> recherche en production. Le code était plein de problèmes et impossible >> à >> maintenir, tout le monde voulait le retirer et le remplacer par quelque >> chose d'autre. Ceci fut la fin de l'histoire de Mozilla et du tracing. >> >> Personnellement, je crois qu'une de mes contributions pourrait être >> spécifiquement au niveau du tracing. Je pense à un design de tracing JIT >> qui n'est pas basé sur les boucles et les longues traces linéaires, mais >> sur un graphe de fragments de code. Les bénéfices du tracing, comme la >> spécialization des fonctions et l'inlining seraient préservés, le >> problème >> de l'explosion des traces pourrait être résolu assez simplement. >> >> Cet après-midi, j'ai pris le temps de regarder un peu le code >> d'IonMonkey, >> tester le JIT inspector, lire des articles recommandés par Luke. Je >> devrais pouvoir rencontrer Michael Bebenita demain matin pour discuter >> tracing. Les gens qui travaillent sur le baseline JIT ne sont pas >> disponible pour me cyber-rencontrer avant mercredi. Je me sent un peu >> inutile ici, mais j'imagine que Mozilla ne s'attend pas vraiment à ce >> que >> je contribue du code. Je vais en profiter pour travailler sur Higgs. >> Comme >> vous disiez, il faut que j'avance mon propre travail avant tout. Si je >> me >> retrousse les manches, je peut avoir du monitoring simple qui marche >> d'ici >> quelques jours. >> >> Je vais réécrire à Alex Gaynor de PyPy demain, j'espère avoir la chance >> de >> le rencontrer. Je vais aussi réécrite à Andrei Alexandrescu pour lui >> dire >> que vous seriez prêt à financer ma présentation à DConf 2013. >> >> - Maxime >

2 1

Presentation de Maxime à Mozilla
by Marc Feeley 04 Fév '13

04 Fév '13

Si vous n'étiez pas à Mountain View pour voir la présentation de Maxime, vous pouvez visionner la vidéo ici : https://air.mozilla.org/higgs-jit/ Je ne sais pas pourquoi la présentation d'Erick n'est pas disponible. Marc

4 4

Fwd: [resolve_2013] Accepted paper #3 "Harnessing Performance for Flexibility..."
by Erick Lavoie 01 Fév '13

01 Fév '13

Article à RESoLVE accepté! Erick -------- Message original -------- Sujet: [resolve_2013] Accepted paper #3 "Harnessing Performance for Flexibility..." Date : Fri, 01 Feb 2013 03:57:07 +0000 De : Robert.Watson(a)cl.cam.ac.uk Pour : Erick Lavoie <acm(a)ericklavoie.com> Copie à : Robert Watson <Robert.Watson(a)cl.cam.ac.uk> Dear Erick Lavoie, The Runtime Environments, Systems, Layering and Virtualized Environments (resolve_2013) program committee is delighted to inform you that your paper #3 has been accepted for presentation at the workshop. We look forward to seeing you in Houston. Title: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity Authors: Erick Lavoie (Université de Montréal) Bruno Dufour (Université de Montréal) Marc Feeley (Université de Montréal) Paper site: http://svr-hotcrp.cl.cam.ac.uk/hotcrp/resolve_2013/paper.php/3?cap=03aKUmFs… Your paper was one of 6 accepted out of 7 submissions. Congratulations! Reviews and comments on your paper are appended to this email. The submissions site also has the paper's reviews and comments, as well as more information about review scores. Please read the reviews and comments and revise your paper and presentation accordingly. Contact the site administrator, Robert Watson <Robert.Watson(a)cl.cam.ac.uk>, with any questions or concerns. - resolve_2013 Submissions =========================================================================== resolve_2013 Review #3A Updated Monday 21 Jan 2013 12:04:51am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== The paper describes instrumentation of JavaScript programs by, in effect, building a metacircular VM implementation. ===== Comments for author ===== I am OK accepting this paper for the workshop -- it is on-topic, and I expect people will be interested in JavaScript instrumentation and debugging. That said, I do not think the presentation of the work is very effective, and (as the paper says) distinction with source-to-source instrumentation is relatively slight. In terms of presentation, I would suggest adding an early running example. In general it is better to start with a simple example that the reasder can understand, and then to move on to the general case. The current paper introduces a lot of abstract detail before getting on to a relatively complex example. I would add (1) a diagram showing the layers and components of the system, (2) a worked example of a single method call and the associated caches. Detailed comments: * "regular semantics of JS", suggest avoiding the word "regular" (it can mean "ordinary", or "orthogonal", or "at fixed periods", so is often ambiguous). * Section 2, I was unclear what level the call, get, send operations are working at -- and if these are actual implementations, or just meant as pseudo-code. Again, I think having a simple example before these details would help explain this better. * Memoized methods -- I was lost at this point. I was unsure if this was a feature of the input JS programs, or an implenentation technique being used by the VM. * The paper should be more candid about perf in the abstract and intro: it is 2x slower than an interpreter, and much slower than a JIT implementation (50x). It would be interesting to look in more detail at the source of the perf costs -- are there particular kinds of instrumentation that are costly? Is there evidence that a smarter underlying VM could strip away un-used instrumentation? =========================================================================== resolve_2013 Review #3B Updated Friday 25 Jan 2013 12:18:29pm UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 4. Accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper discusses the creation of a metacircular JavaScript virtual machine as a means of instrumenting JavaScript code without having to maintain an instrumentation framework alongside a complex performance oriented JIT VM. The authors propose using message sending semantics as the means of building this VM, which, when executed on top of a state-of-the-art JIT based javascript VM, provides acceptable performance in comparison to a modern interpreter based JavaScript VM. ===== Comments for author ===== This is an on-topic paper which should be of interest to attendees of the RESoLVE workshop. I think the message sending based techniques used to build the metacircular VM is interesting, as are the insights that they can perform code cacheing using the dynamically specializable abilities of Javascript. However, the paper's presentation makes this work difficult to follow. The paper dives right into the low-level techniques used to build the VM, with no real discussion of how these techniques relate to the "compilation" of user-level code. Then, in section 4 a compilation example is presented, but this example is quite complex and it's difficult to follow how the previously discussed techniques are used in it. I think the paper could be improved by having a simple running example which permeates the implementation discussions to help describe them, then put all these running examples together in Section 4 to show how the approaches work together. I also struggled to clearly understand when and where the optimizations to the code cache were happening. For example, how does the __memoization__ tag interact with the virtual machine. This might be clearer if the authors presented the transformations for a simple compilation example and described where the VM interacts with the source-to-source translated user code in order to carry out these transformations. Also, the use of the word memoization seemed a bit misleading, since it would imply that the function's result is memoized meaning the function doesn't need to be called at all, whereas what is being discussed in the paper is the memorization of the message send operation, while the user-function is still being called. Finally, it would have been interesting to see how instrumentation is inserted into the compiled code - there is very little information given on the implementation of Pn-spl or Pn-fast presented in the evaluation. I would have been interested to discover how the two approaches differ in more detail as well as some discussion on how tied Pn-fast is to the current VM implementation, and whether changes in the VMs implementation would require significant work to ensure the instrumentation features still worked correctly. Overall though, I think this paper would be a worthwhile addition to the RESoLVE workshop. =========================================================================== resolve_2013 Review #3C Updated Sunday 27 Jan 2013 4:59:40am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 2. Weak reject Reviewer expertise: 2. Some familiarity ===== Paper summary ===== This paper describes the a Javascript instrumentation framework that relies on meta-circular evaluation to simplify its construction. The paper describes a few optimizations that reduce the overhead of instrumentation. It finally describes preliminary performance results comparing the new Javascript VM (Photon) with a interpreter (SpiderMonkey) and a JIT-based (V8) VM. ===== Comments for author ===== This was a difficult paper to read. Perhaps I would be more positive about the work if I had an easier time grasping some of the concepts presented. Unfortunately, I still have several basic questions that I was unable to answer. So, more than anything, I'd encourage the authors to improve the presentation of the work so that readers can fully understand its technical value. A few suggestions: * The Introduction does not clearly describe what problem this work addresses, and how it proposes to do so. It is important to describe what type of instrumentation this work attempts to perform (and why). I did not find this anywhere in the paper. Furthermore, why is it important to make instrumentation a separate entity (is instrumentation targeted to writers of Javascript VMs or applications writers?). Certain phrases, such as, "Our approach relies on an object representation based on proxies that exploit a previously unexploited constraint: the prototype chain of the proxies mirrors the prototype chain of the objects" are difficult to begin to parse without the context of the remainder of the paper. Even then, I find it challenging. * Closed-world vs Open-world assumptions. First, please define these terms more carefully in your context. The terms I knew were from the area of formal logic, and it is not clear how they apply in your context. More importantly, why does it matter which type of system you build? Do these provide the same functionality to your target instrumentation? * A premise in this work is that meta-circular evaluation will make building VMs with instrumentation easier. Do you believe that new Narcissus VM, also based on meta-circular evaluation, will make instrumentation JS code easier? Or is it simply a function that the VM proposed in this work is small and highly customized to provide instrumentation hooks? * Because I did not understand the introductory questions above, I was left wondering if going through the trouble of building a new VM based on multi-circular evaluation is worth the trouble. For example, there are numerous projects that perform compilation to Javascript (see: http://altjs.org/). Also, given that I'm not sure about the level of instrumentation desired, it seemed that this work was largely replicating the concepts of Aspect-Oriented Programming, where the instrumentation is designed as aspects for specific JS objects. And a simple plugin to JQuery allows one to extend JS object behavior using AOP (which just a couple hundred lines of JS code; also the overhead of this is expected to be minimal and only dependent on the instrumentation itself): https://code.google.com/p/jquery-aop/ * About the messaging. Please first explain, at a high-level, why you decided to base your system on messaging, and how it is used in your system. Second 2 started discussing messaging as if I had knowledge of its purpose in the overall system design. As a consequence, all of Section 2 was very confusing. What's the difference between messages and a simple method invocation? Why is it necessary to wrap method calls as messages? * It seems that a fundamental Javascript feature that this work leverages is the ability to evaluate code at run-time (eval() function). It would be helpful to clearly explain this in the paper (maybe in a section describing the high-level concepts of Photon, before describing the messaging layer, for example). * In the experimental section, we see that Photon reduces the performance of V8 by 200x. This is quite significant, and would make be weary to use such a heavy-weight instrumentation framework. For example, for identifying hot-spots, it is not clear that this instrumentation framework would not significantly alter the performance behavior of execution, making any conclusions from this framework unreliable. * A minor point, also in the experimental section, one data point stuck out. In Table 9, Pn-fast receives a 25% performance boost over Pn for DeltaBlue. The only justification is that these are "natural variations of results". I find this to be a non-trivial variation in execution, and would urge future versions of this work to attempt to improve (or quantify) the statistical significance of the results. =========================================================================== resolve_2013 Review #3D Updated Monday 28 Jan 2013 10:04:57am UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 2. Some familiarity ===== Paper summary ===== The authors use a hierarchy of proxy objects to "wrap" an application's own object hierarchy and use this to instrument the application. The same wrapping mechanism is used to also support inline-caching optimizations to reduce the overhead of instrumentation. In all cases, the approach exploits the proxy feature which will be coming in future versions of JavaScript. ===== Comments for author ===== What if application already uses proxy objects? How are these instrumented by the additional hooks? What are the (circularity) issues here and how do different attempts at instrumentation compose? Some questions about the performance section: + explain what the baseline is better at the start of section 6 (indirection through proxies, on V8) + what is the impact of conservative assumptions for simpler invalidation of caches, etc.? + in tables 7 and 9: what does "v8 score" mean? isn't this geo mean? + the tables would read better as graphs Have the authors looked at frameworks like the Spring (aspect-oriented) framework that does something like this in a less general way to build large Java applications? Minor comments: Introduction: "running of the VM" --> "running on the VM" Table 3: "Lookup method then call." --> "Look up method, then call." Table 4: "has his method being updated" --> "has its method updated" Section 3.2: "requires to specialize" --> "requires us to specialize" Section 4: "syntax tree nodes as preserved." --> "syntax tree nodes are preserved." Section 5: "is in most cases, is also" --> ", in most cases, is also" Section 6: "they have the same name" --> "they have the same name." "should the prototype of an object changes" --> "should the prototype of an object change" =========================================================================== resolve_2013 Review #3E Updated Wednesday 30 Jan 2013 8:12:23pm UTC --------------------------------------------------------------------------- Paper #3: Harnessing Performance for Flexibility in Instrumenting a Virtual Machine for JavaScript through Metacircularity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper focuses on the low-level details of instrumenting OO accessors and method calls in Javascript by transforming programs into a proxy-based message-sending representation. The paper gives details of the model, the code transformation required including consideration of various corner cases, and an empirical performance analysis. The work exists in a vacuum - in that little motivation is given for instrumenting Javascript programs. Further there is only limited discussion (in opening paragraphs of sec 1, closing paras of sec 5) about alternative approaches to Javascript instrumentation. In summary - a detailed technical paper, which could be of interest to RESOLVE workshop attendees. Hence weak accept. ===== Comments for author ===== Generally clear where the paper is going - although given the amount of technical details sometimes it is difficult to see the wood for the trees. I would appreciate more high-level motivation personally. Sect 5.5 - related work - make this a new top-level section, rather than a subsection. You show how this proxy-based technique can be useful for whole-program instrumentation - e.g. for counting number of method calls etc. Could it also be a good approach to dynamic aspect weaving for prototype-based languages?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Dlteam-list Février 2013