|
|
|
| Authored by: dio gratia on Saturday, May 12 2012 @ 11:07 PM EDT |
If that's the case, there may be this misapprehension on Oracle's counsel's part
that Oracle practices the patent when they in fact do not. It would explain
their blind insistence that Google does too, and reflect a lack of patent
expertise.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, May 13 2012 @ 11:58 AM EDT |
The symbolic references HAVE ALREADY BEEN RESOLVED in the bytecode.
Here is an alphabetized list of names and memory location values (sorted names
are faster to search, as was discussed with Judge Alsup):
Beers: 0
Cats: 2
Dogs: 1
The numbers symbolically represent the memory offset where the data is stored.
The block of memory would look like this (each set of digits is one byte, in
base 10 (decimal) ):
[ 99 ]
[ 6 ]
[ 9 ]
So, If I want to see how many dogs there are:
java.lang.System.out.println( dogs );
The compiler must know where in memory the "dogs" variable is -- We
can see this because I already gave you the memory layout, but the compiler
would have performed these steps.
To resolve "dogs" into a memory address, you look up in that name to
address symbol table, and find the value 1.
If you do that at compile time or load time it generate bytecode that will:
"Print the value stored at memory address 2"
the number "6" would be printed.
If you instead do this dynamically, the bytecode would contain an instruction
that said:
"Look up the memory address of 'dogs' and print the value stored
there"
Now, it would be faster to just remember that "dogs" is located at
address 2, and the '104 patent's claim is that if you are running the code, and
you come across code that does such a dynamic lookup for a NAME, then re-write
the bytecode that says:
"Look up the memory address of 'dogs' and print the value stored
there"
So that you don't have to look it up next time:
"Print the value stored at memory address 2"
If you do that, then it's covered by the patent. That's all it is -- It's
called memoization, and everyone has done this, long before Java.
However, NEITHER Davlik bytecode OR Java bytecode has ANY instructions that
say:
"Look up the memory address of 'dogs' and print the value stored
there"
Instead, that symbol table that contains the names that HAVE ALREADY BEEN
RESOLVED to memory addresses is stored in the .class or .dex file. (the name
table is not executable bytecode, and is not modified at runtime).
So, the running Davlik the bytecode would only say:
"Print the value stored at memory address 2"
---
Now at load time the .dex file might have an instruction like this:
"Get the memory address from the third table entry and Print the value
stored there"
Java prefers to do this at run-time, for faster start up, because Java web
Applets are typically not "installed" and persistent, why resolve
every symbolic reference before starting to run if you might not use them all?
Not that there are no NAMES in that statement, only memory addresses.
"third table entry" would be given as a memory address of the table
plus the slot number -- NO NAMES.
The names "dogs" & "cats", etc are irrelevant to the
execution of byte code. The VM doesn't care. The only reason that the ALREADY
resolved names are there is so that THE DATA can refer to the NAME (not the name
referring to the data). This is so you can ask: What was the third table entry
named before it was compiled? You jump straight to that table entry and find
"Dogs" -- no resolution, no searching. You're not modifying that
lookup. This is called reflection (as in reflecting on the past) and it has
nothing to do with the patent.
Neither Java or Davlik byte-code exercises the patent's claims! Even at Load
Time![ Reply to This | Parent | # ]
|
|
|
|
|
