On 08/09/2013 04:29 PM, Nicolas B. Pierron wrote:
I don't think we should use tainting. The extra bit on the length is
currently reserve to optimize strings which would be represented as an
int.
If using another bit is infeasible, then we can find other approaches.
Tainted strings are usually rare; if we could find a single unused
JSString type code, we could have such JSStrings point to the real JSString.
The goal of the tainting is to re-construct the inverted data-flow
graph, i-e finding the origin of a string which flow into a function.
And the data-flow graph is basically what is monitored when we
register that we can see a new values flowing inside a store at a
specific code location.
I think that if we want to capture this kind of information, we should
at least make it in such a way that we can also use it to improve our
performance. If we are able to isolate the data-flow, we could
optimize our data representation based on guarded invariants of the
data-flow (dynamic deforestation?), and with the support of a moving
GC, we could optimize/deoptimize the value representation on GCs. [to
be seen as a JIT compiler for the data flow instead of only having JIT
compilers for the control flow]
It's true that, in principle, the flow graph the compiler uses and the
flow graph taint analysis uses are the same. But in practice they're
very different.
* Taint is concerned with flow *through* string primitives:
concatenation, substring, regexp match extraction, and so on. The
compiler doesn't know much about those operations, and so is only
concerned with getting them their arguments, and delivering their
results to the right place. It doesn't relate their inputs to their
outputs.
* Taint needs to dynamically observe the flow of values in specific
actual executions. If a particular branch isn't taken, then the
not-executed code shouldn't affect taint results. But the compiler
needs to reach conservative conclusions that hold on all possible
executions.
What you propose would require substantial contributions from a group of
engineers (IonMonkey and GC hackers) that is in high demand; it's hard
for me to imagine taint support becoming a sufficient priority for that
team - especially since it's an unproven approach. In contrast, the
taint analysis I brought up here has been prototyped and shown to be
valuable, and is within reach of a volunteer (Ivan) from the security team.
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
