|
Abstract: Web 2.0 applications such as Gmail and Google Docs are
becoming indistinguishable from traditional native desktop applications. The
main reason for this is greatly increased JavaScript performance in modern web
browsers, to which significant contributions were made right here at UCI.
At UCI, we invented "Trace Compilation", a
radically new way of building dynamic compilers. We then teamed up with Mozilla
to build "TraceMonkey", the first just-in-time compiler for
JavaScript ever, which became a standard part of Firefox starting with version
3.5. Close to a billion people are now benefiting from our research every day.
Other groups of researchers that are now using trace compilation include Adobe,
Google, Microsoft, and Oracle, and we are collaborating with several of their
projects.
I will introduce the technology behind Trace Compilation,
which is very different from any compiler technology described in any current
textbook. Common to practically all compilers built over the past 50 years has
been the concept of the "control flow graph", a model of a program
that a compiler builds and then traverses while generating target code. Even
just-in-time and embedded compilers have been using such control flow graphs,
although they tend to make the unit of compilation smaller than traditional
batch compilers (e.g., one method at a time rather than one class at a time).
Conversely, in a trace compiler, a novel intermediate representation, the Trace
Tree, is constructed lazily on-demand while the program is simultaneously
executed, incrementally compiled, and optimized. The advantage of this
technique is that the compiler doesn't expend any resources on parts of the
program that are not frequently executed; traditional compilers construct
control-flow graphs for unimportant and even for unreachable parts of a program
and need to prune such graphs later.
Besides trying to make software run faster, compiler
researchers are also increasingly working in areas related to security. At UCI,
for example, we have been investigating compiler-generated software diversity
as a defense mechanism against software attacks. Imagine an "App
Store" containing a diversification engine (a "multicompiler") that
automatically generates a unique version of every program for every user. All
the different versions of the same program behave in exactly the same way from
the perspective of the end-user, but they implement their functionality in
subtly different ways. As a result, any specific attack will succeed only on a
small fraction of targets. An attacker
would require a large number of different attacks and would have no way of
knowing a priori which specific attack will succeed on which specific target.
Equally importantly, this approach makes it much more difficult for an attacker
to generate attack vectors by way of reverse engineering of security patches.
|
