When you write some Java code like:
static int[] tester = {1, 2, 3,
4};
what a Java compiler does, is emit bytecodes into the method
(class initializer). Those bytecodes will create the array, initialize the
slots of the array with those values (1, 2, ...) and assign the array reference
to the field. It's not like a C program, where the compiler would just put
already-initialized data straight into a .data or .rdata segment. The Java
compiler emits actual code to do the initialization at run-time. (my wild guess
is that it was originally done that way for safety/simplicity reasons, and then
they came up with a specific idea to make it run faster, which is what is
covered by the '520 patent).
What is described in the '520 patent is something
called "clinit optimization". I think it's performed by the Java compiler, the
intent being to save time for the VM when it loads the class (or when is
actually invoked, which I think can be at a later time). The '520 patent
describes an algorithm that looks at the bytecodes, figures out "these bytecodes
are an array initialization with no side effects", and replaces them with a
single bytecode that says "just copy this whole blob of data". The benefit is
minor for a small array; its very helpful for bigger arrays, if they are e.g.
1000 slots long, then it would to execute over 2000 bytecodes to initialize them
the "slow" way, and that can be replaced by a single bytecode that says "copy
1000 values from here, into the array".
Anyway, since Dalvik's file format
doesn't have to match Java's .class format, they were able to do something
smarter. It sounds like they just emit a statically-initialized data section at
compile time (i.e. dexopt time). That's much the same thing that C compilers
have been doing for fifty years. It's
briefly mentioned here in the section "Use Static Final For Constants". [ Reply to This | Parent | # ]
|