|
|
|
| Authored by: Anonymous on Friday, May 11 2012 @ 07:12 PM EDT |
Google exposed this on redirect, but they'd better hammer that point in their
closing statement, because (from the report here) they may not have put enough
emphasis on it in the jury's mind...
MSS2[ Reply to This | Parent | # ]
|
| |
| Authored by: YurtGuppy on Friday, May 11 2012 @ 07:38 PM EDT |
Oracle and Google are also tussling over
dynamic and static.
Dynamic: it happens while the app is running
Static: it happens any other time (in this case, before)
Imagine a trip to the grocery store (you are executing the brain-program
"trip to store").
A static optimizer looks at the map, rubs it's chin and sees the shorter route
before you've started off.
As you travel, a dynamic optimizer would say "No! turn here and we'll get
there faster!"
Static - changing the plan before you start out
Dynamic - changing the plan while the plan is in execution
So McFadden says there isn't any data during the static optimization, the app
isn't running. No sloshing around of network packets or whatever. The app is a
cold dead nothing.
Oracle tries really hard to get the word "dynamic" to come out of
McFadden's mouth. At the end they change the context just to get the word to
appear.
---
a small fish in an even smaller pond[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 11 2012 @ 09:12 PM EDT |
I agree with your analysis here. The Oracle lawyers simply don't understand the
difference between a symbolic reference and an indirect reference. These two
terms are chalk and cheese, and they're certainly not disputed as they go back
to the 60's at least. Oracle's case has a mistaken foundation as a matter of
fact.
The trouble is, this is obvious to us because we have the required CompSci
background, but the jury does not. Google still has some work to do to make
this rather dramatic mistake plain to the jury and to make sure they realize
that it's not just a matter of opinion.
After all, these are two completely different concepts, and you can't have the
patent cover one concept but the verdict be based on use of the other.[ Reply to This | Parent | # ]
|
| |
| Authored by: Guil Rarey on Friday, May 11 2012 @ 10:06 PM EDT |
Just to provide definitions of:
dynamic
static
symbolic reference
reference resolution
indirect index (or correct term of art)
index lookup (to contrast reference resolution)
1)As they are used in computer science and
2)When those terms and their usage became standard within that discipline
Just to clarify for the jury that these terms have specific, well-understood
technical definitions which were well-established long before this patent was
written.
Also, can you imagine qualifying him as an expert? "Look your Honor,
imagine that John Marshall, Learned Hand, and Oliver Wendell Holmes *together*
just strolled in to give you a few pointers on your opinions. It's like
that." No, I know, that's not how it works. But imagine Oracle objecting
on the grounds that Knuth hasn't even managed to complete his primary work.
"You've only managed to complete 4 volumes of a 7 volume work. How do we
know you're really an expert?"
---
If the only way you can value something is with money, you have no idea what
it's worth. If you try to make money by making money, you won't. You might con
so[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 11 2012 @ 11:33 PM EDT |
| Because I keep getting the two confused, let me summarize them both
here:
US Patent
6,061,520 is about the "clinit optimization".
This is where the Java
compiler (or the VM? I'm not sure) simulates execution of some of the bytecodes
in the <clinit> method, to figure out what values those bytecodes will put
into an array (the optimization only applies to arrays that are initialized with
a bunch of numbers, or other values).
Although Android also has an
optimization for array initialization in <clinit>, their version doesn't
infringe the '520 patent because it doesn't simulate execution of the
bytecodes at all (which would require tracking the effect of each bytecode
on a stack). Android uses a completely different, much simpler technique:
pattern matching. It just checks for the expected pattern of bytecodes, and
whenever its found it says "yup, thats an array initialization" and steals the
numbers from the proper parts of the pattern. Because of this, it can't cope
with other patterns which would also be valid array initialization code,
but who cares, because all Java compilers actually emit the same simple
pattern!
US Patent
RE38,104 covers dynamic resolving of a symbolic reference which is embedded
in a bytecode instruction, and then replacing that bytecode instruction with a
different one containing the resolved index (so that you won't have to resolve
it all over again the next time you execute that instruction).
This is just
an example of a standard decades-old CS technique called memoization, and its
absolutely shameful that a patent was issued for it (even if the patent is
limited to using memoization in this specific kind of situation, its still
ludicrous). If the patent office doesn't reject this patent, I will just
cry.
Anyway, Google doesn't infringe this one for several reasons: it covers
a dynamic bytecode-replacing optimization, and to the extent that dexopt
does a similar bytecode-replacing optimization, it is a static
optimization (it doesn't happen at run-time, but rather when the application is
compiled or installed). Also it requires resolving a symbolic reference
which is embedded in a bytecode instruction, and Dalvik doesn't have
symbolic references in its bytecode instructions. They are stored in a
different part of the .dex file and referred to by index. It also sounds like
they are not resolved lazily during the program's execution, the way Java VMs do
it. Instead, it sounds like in Android, they are resolved by the dexopt tool
before the application can even be run. (In other words, they are resolved
"statically", not "dynamically").
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, May 12 2012 @ 05:54 PM EDT |
Minor nitpick: A symbol isn't necessarily a string. In fact, it could be a
number, and you could have symbolic references based on numbers *as symbols*;
this would be implemented in the same basic way, where a reference table maps
the number to the corresponding data. The core distinction here being, the
numbers may or may not be sorted, and they may not be consecutive: just because
there's a data location associated with 1, 3, 4 and 5 doesn't mean there's any
data location associated with 2. (I wonder if that's why the judge focused so
heavily on the missing '1' in that testimony, where only the locations of the
start of an instruction were numbered. I hope that's been adequately
clarified.)
This contrasts with what the witness called 'numeric reference' and what I might
call 'indexed reference', or 'pointer arithmetic' for C buffs. In that case, the
location of the data is inherently derivable from a known location and the
number itself. For instance, in C, the syntactic sugar for finding the fourth
element in an int array called 'z' is z[4]. This is actually implemented as and
equivalent to: z+4*sizeof(int); i.e. so long as you know where the array is (and
the size of the data it contains), the numeric reference gives you everything
you need to *arithmetically calculate* the location of the element you want. No
searching involved.
The important take away here is that there is a fundamental difference between
mapping symbols (units of meaning which can be extremely diverse) to data, which
has a cost, and imposing an ordering on data which allows its location to be
derived independently of any such mapping (which can have its own radically
different costs)[ Reply to This | Parent | # ]
|
| |
| Authored by: jjs on Sunday, May 13 2012 @ 02:23 PM EDT |
What's described here is similar to Intel indirect memory - it stores a pointer
to the actual location. Used since at least the 8086 (not certain about the
8080, 8008), which was, well, more years ago than needed for the patent to have
expired. And I'm certain (but without proof) it goes back well before that.
This is really old-school stuff.
---
(Note IANAL, I don't play one on TV, etc, consult a practicing attorney, etc,
etc)
[ Reply to This | Parent | # ]
|
|
|
|
|
