On Jun 26, 2014, at 6:57 AM, Nicolas B. Pierron <[email protected]> wrote:
> I have a question for you, and also for people who have made such analysis in > SpiderMonkey. Why taking all the pain of integrating such analysis in > SpiderMonkey's code, which is hard and change frequently when it would be > easy (based on what you mention) to just do source-to-source transformation? > > Why do we have 3 propositions of implementing taint analysis in SpiderMonkey > so far? It sounds to me that there is something which is not easily > accessible from source-to-source transformation, which might be easier to get > hooked once you are deep inside the engine. Perhaps we can get those who tried to implement taint analysis in SpiderMonkey before to chime in about the pain points they experienced. Do we know who they are? > I understand your argument saying that we should support transformations on a > support which is standardized. Maybe this is just a matter of naming the API > properly such as the analysis feel like that are being hooked on the Specs > definitions of JavaScript. It seems to me you can’t have your cake and eat it too. IIUC, you are proposing an API that’s SpiderMonkey-specific and is tailored to its extensions. How is that going to play with the official spec? Why entangle spec language? Should this API be kept up with the spec? I also foresee scaling/implementation problems by designing hooks around the ES spec, as that goes well beyond monitoring bytecode, but would require manual instrumentation of many VM functions (e.g., prototype chain walks, lexical environments). > Extending a JS parser, maybe. Extending 2 JS parser the same way, is harder. > >> New language features with complex semantics require significant tool >> updates whatever API we use. > > No as much as the syntax, the bytecode is an example of it, as the bytecode > is some-kind of subset that we target with the bytecode emitter. As you > mentionned, manipulating bytecode is easy, but manipulating the source to > ensure that we have the same semantic might be more complex. It seems a worse maintenance burden to me to have to update all analyses written when we decide to change the bytecode in SpiderMonkey, say, like decomposing some more fat ops. Exposing a bytecode-based instrumentation on a private bytecode makes the bytecode a de facto public and frozen API, which is undesirable. As I’ve said before, which I’ll repeat here for the benefit of the discussion thread, I am in favor of a source-to-source approach because it seems to me that source-to-source is just as expressive as the API proposed here. I remain optimistic that an out-of-engine tool can be made performant, for some of the points roc mentioned. For maintenance, if nothing else, an out-of-engine tool is open to be maintained by a larger number of developers instead of just JS engine developers. If we discover fundamental performance and expressivity limitations that an out-of-engine tool poses, I would be swayed in the other direction. - shu _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
