|
Authored by: Anonymous on Friday, May 11 2012 @ 09:04 PM EDT |
Trying to confuse "symbolic reference" (a string) with an index.
Gringo
Sent from my Android phone
[ Reply to This | Parent | # ]
|
|
Authored by: matth on Friday, May 11 2012 @ 09:54 PM EDT |
Their twist on what's a symbol reference is egregious as well. [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Saturday, May 12 2012 @ 01:47 PM EDT |
Its the BSF trick of transposing two different words; 'running' -vs- 'runtime',
and pretending they mean the same thing. The normal usage of 'dynamic' only
applies to one of those.
[ Reply to This | Parent | # ]
|
- Standard BSF - Authored by: PJ on Saturday, May 12 2012 @ 01:52 PM EDT
|
Authored by: Anonymous on Saturday, May 12 2012 @ 02:47 PM EDT |
Okay, this is hilarious.. its not just Dalvik bytecodes that don't contain the
symbolic reference in their instruction stream. Java bytecodes don't either!
The symbolic reference is stored in a constant pool entry, and the Java bytecode
(e.g. "invokevirtual") contains a numeric index into that pool.
What this
means is that the '104 patent doesn't even cover a Java VM! They mangled the
language when translating it into lawyerese, resulting in an "invention" that
differed from their actual practice. An "invention" that probably doesn't cover
any VMs in actual use, because its a stupid design.
How the
Java virtual machine handles method invocation and return, an article from
1997:
Dynamic linking
Because Java programs are
dynamically linked, references to methods initially are symbolic. All invoke
instructions, such as invokevirtual and invokestatic, refer to a constant pool
entry that initially contains a symbolic reference. (See my earlier column, "The
Java class file lifestyle," for a description of constant pool.) The symbolic
reference is a bundle of information that uniquely identifies a method,
including the class name, method name, and method descriptor. (A method
descriptor is the method's return type and the number and types of its
arguments.) The first time the Java virtual machine encounters a particular
invoke instruction, the symbolic reference must be resolved.
To resolve a
symbolic reference, the JVM locates the method being referred to symbolically
and replaces the symbolic reference with a direct reference. A direct reference,
such as a pointer or offset, allows the virtual machine to invoke the method
more quickly if the reference is ever used again in the future.
For example,
upon encountering an invokevirtual instruction, the Java virtual machine forms
an index into the constant pool of the current class from the indexbyte1 and
indexbyte2 operands that follow the invokevirtual opcode. The constant pool
entry contains a symbolic reference to the method to invoke. The process of
resolving symbolic references in the constant pool is how the JVM performs
dynamic linking.
However, that linked article does confirm
that Java VMs resolve these symbolic references "at run-time". I think Dalvik
does too (I am not sure). However, its version of the bytecode-replacing
optimization that Oracle claims is infringing the '104 patent is NOT done "at
run-time". If it is done at all, it is done by dexopt (at compile-time or
install-time). Not by the Dalvik VM, but by these other "off-line" tools.
That's why its a "static" optimization in Dalvik, where the '104 patent appears
to claim a "dynamic" process.
Lets look at claim 1 of the
patent:
1. In a computer system comprising a program in source code
form, a method for generating executable code for said program and resolving
data references in said generated code, said method comprising the steps
of:
a) generating executable code in intermediate form for said program
in source code form with data references being made in said generated code on
a symbolic basis, said generated code comprising a plurality of instructions
of said computer system;
b) interpreting said instructions, one at a
time, in accordance to a program execution control;
c) resolving said
symbolic references to corresponding numeric references, replacing said symbolic
references with their corresponding numeric references, and continuing
interpretation without advancing program execution, as said symbolic references
are encountered while said instructions are being interpreted; and
d)
obtaining data in accordance to said numeric references, and continuing
interpretation after advancing program execution, as said numeric references are
encountered while said instruction are being interpreted;
said steps b)
through d) being performed iteratively and
interleaving.
(emphasis mine).
I suspect this doesn't
actually describe what a Java VM does. The Java VM encounters a bytecode which
contains a numeric index (into the constant pool) and it chases that,
then it resolves the symbol found in the constant pool, then it
overwrites the bytecode opcode&operand with different ones (but does not
change anything in the constant pool). So it does not "replac[e] said symbolic
references with their corresponding numeric references" at all. It replaces one
numeric index-based bytecode with a different numeric index-based bytecode and a
different index (which because it is a different bytecode, would now have a
different meaning even if it happened to still be the same number). Nowhere in
this process does it replace "the symbolic reference" at all!
Off to eat
lunch, and ponder all of this foolishness some more! [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Saturday, May 12 2012 @ 07:08 PM EDT |
They are trying to prove nonsense. When you need to prove nonsense you have to
speak nonsense.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Sunday, May 13 2012 @ 11:51 AM EDT |
Even bricks are dynamic if you heat them until they crack. [ Reply to This | Parent | # ]
|
|
|
|
|