On 06/26/2014 10:49 AM, Shu-yu Guo wrote:
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?
Yes, we know who they are, and we contact for all of them.
But I know that at least one of them does not want to go public right now.
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.
I do not disagree that source-to-source is more expressive, but it is as
well easier to shoot your-self in the foot, by doing such modification.
I want to make sure that this is both as easy for analysis developers to
make analysis as it is for us to maintain such API.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
