|
|
|
| Authored by: bugstomper on Tuesday, May 22 2012 @ 09:26 PM EDT |
"If there is no symbol that refers to a piece of data, then there is no
symbolic reference"
In the iget instruction there is a symbol that refers to a piece of data. The
iget instruction would be written in assembler source code as iget
vx,vy,field@CCCC where CCCC is a hex number. In the byte code of the
instruction, field@CCCC is a 16 bit number that is an index into the field
table. The entry in the field table at that index contains three numbers, each
of which is an index or an offset into another table. Those three numbers refer
to a class, a string that is the name of a field in that class, and a string
that is the type descriptor of the field.
In order to execute the iget instruction, there has to be a search of a table of
fields of the class looking for the one whose name string matches the specified
name string, and whose type descriptor string matches the specified descriptor
string. Once that match is found, the iget instruction with the symbolic
reference to the field that is field@CCCC is replaced with an iget-quick
vx,vy,offset where offset is a number that is the offset into the instance of
the field that has the specified name.
iget vx,vy,field@CCCC as an instruction means load register vx with the value of
a field of the instance pointed to by register vy, the field to use being the
one whose name is the string referenced by the second word at field table
element number CCCC.
iget-quick vx,vy,offset does the same thing, but the field to use is whatever is
at that numeric offset in the instance object.
dexopt uses the field@CCCC operand to get the field name as string from the
CCCCth entry of the field table, looks up the name in the list of fields for the
specified class, and when it finds the field with the right name takes the
numeric offset of that field in the instance and turns the iget instruction into
the equivalent iget-quick.
By any sane definition, that is a process of symbolic reference resolution. It
happens in dexopt at install time, resulting in a file that does not contain
symbolic references, to be executed later. By any sane definition that is
static, not dynamic.
Google has a point that we are not necessarily dealing with a sane definition.
We are dealing with the language of the claims in the patent. There may be no
requirement in the law that claims be construed to mean what we know the actual
inventor intended when the words of the claim say something different, even when
what they say makes no sense in the real world.
I suspect that Google's lawyers made the decision to not push it in the claim
construction phase to avoid having the judge explicitly rule that the amount of
indirection in iget is still "instruction containing a symbolic
reference". They preferred to take their chances on convincing the jury to
use the literal meaning of the phrase, especially with Figure 8 in the patent
showing LOAD "y". That seems sleazy to me, to try to convince the jury
of something that is pretty certainly not what the inventor intended. But in a
world where they could lose on the point about dynamic vs static because of
Oracle's bamboozling of the jury, perhaps they feel they have to take every
little advantage they can get.
The just result would be for Google to lose on the point about symbolic
reference, but win on the '104 patent as a whole because dexopt does not do it
dynamically.
[ Reply to This | Parent | # ]
|
|
|
|
|
