| Why would Dalvik contain a Simulator class, if not for the express purpose
of
infringing Sun's stupid '520 patent, I hear the audience wondering?
Simple!
Java bytecodes are for a stack-based VM, and Dalvik uses a
different
register-based bytecodes system. So the dex compiler has to
figure out what
the effects of a group of Java bytecodes are, so it can turn
them into Dalvik's
register-based bytecode.
To do this, it has to _simulate_ what those
bytecodes do (a combination
of manipulating the Java stack, and causing other
side effects like
reading/writing memory) and as the simulation discovers side
effects, it
emits its own bytecodes that have the same side
effects.
Ironically, dex uses simulation for translating almost all of the
bytecodes,
EXCEPT for the specific bytecodes used for this clinit array
initialization
that the '520 patented optimization is about. Dex can also
optimize those
bytecodes, but it uses a different--and much simpler--mechanism
for
doing it, which avoids the '520 claims.
...So why do they need a
Simulator class at all? Good question. Actually,
they could have used pattern
matching for everything, and programmed in
all of the patterns actually used by
Java compilers. But it would have
been a lot of patterns, it would have been
complex and still brittle.
Bytecode optimisers or obfuscator tools might
re-arrange bytecodes into
unrecognised patterns. Programmers might assemble
unusual bytecode
patterns by hand. Future Java compilers might emit new and
unrecognised patterns. Any of these would have caused Dex to be unable
to
convert the program, which would be bad. No, simulation with the
Simulator
class is a better approach for the general translation of tbe
bytecodes,
because it can handle any Java bytecodes that a Java VM
would accept.
But
for optimising the specific feature of array initializers, pattern matching
was
a great choice, because:
(1) its simple, and there's only one pattern that
all of the known compilers
use for this, and:
(2) its only an optimization.
If it misses one because somebody emitted a
different pattern of bytecodes, the
translated program will still work--it will
just be a little bit bigger and
slower.
Dex either detects the pattern and optimizes an array
initialization, or it
DOESN'T detect the pattern, and DOESN'T apply the
optimisation, and
instead it simulates and translates the individual
bytecodes.
The '520 patent covers doing BOTH things at the same time:
simulating
the bytecodes and using the info collected during that
simulation to
do the optimisation. Dalvik never does both together, it
either does one or
the other. [ Reply to This | Parent | # ]
| 
