Oracle America, Inc. v. Google Inc.

Filing 497

Declaration of DANIEL PURCELL in Support of #496 MOTION in Limine No. 5, #494 MOTION in Limine No. 3, #492 MOTION in Limine No. 1, #493 MOTION in Limine NO. 2, #495 MOTION in Limine No. 4 filed byGoogle Inc.. (Attachments: #1 Exhibit 1, #2 Exhibit 2, #3 Exhibit 3, #4 Exhibit 4, #5 Exhibit 5, #6 Exhibit 6, #7 Exhibit 7, #8 Exhibit 8, #9 Exhibit 9, #10 Exhibit 10, #11 Exhibit 11, #12 Exhibit 12, #13 Exhibit 13, #14 Exhibit 14, #15 Exhibit 15, #16 Exhibit 16, #17 Exhibit 17, #18 Exhibit 18, #19 Exhibit 19, #20 Exhibit 20, #21 Exhibit 21, #22 Exhibit 22, #23 Exhibit 23, #24 Exhibit 24, #25 Exhibit 25, #26 Exhibit 26, #27 Exhibit 27, #28 Exhibit 28, #29 Exhibit 29, #30 Exhibit 30, #31 Exhibit 31, #32 Exhibit 32, #33 Exhibit 33, #34 Exhibit 34, #35 Exhibit 35, #36 Exhibit 36, #37 Exhibit 37, #38 Exhibit 38, #39 Exhibit 39, #40 Exhibit 40)(Related document(s) #496 , #494 , #492 , #493 , #495 ) (Kamber, Matthias) (Filed on 10/7/2011)

Download PDF
EXHIBIT 8 UNITED STATES DISTRICT COURT NORTHERN DISTRICT OF CALIFORNIA SAN FRANCISCO DIVISION ORACLE AMERICA, INC. Case No. CV 10-03561 WHA Plaintiff, v. GOOGLE INC. Defendant. SUMMARY AND REPORT OF NOEL POORE SUBMITTED ON BEHALF OF PLAINTIFF ORACLE AMERICA, INC. pa-1474101 II. BACKGROUND AND QUALIFICATIONS 8. In 1985, I received a BA in Computer Science from Cambridge University, Cambridge, England. 9. I have many years experience of working with system software for mobile devices. From 2001 to 2008 I worked as a senior technical executive for SavaJe Technologies, a company which developed a complete Java platform for smartphones. SavaJe was acquired by Sun, which was later acquired by Oracle. Both in this role and in previous roles I gained a lot of experience of measuring and optimizing the execution time and memory consumption of code for mobile devices. 10. I am currently the lead architect for embedded middleware in JDK8 Embedded. I am also the technical lead of a group which provides Java technology for iOS and Android applications. 11. I am qualified to conduct performance analysis and analyze the results obtained because I have many years experience of developing, performance testing, benchmarking, and optimizing embedded Java software. At SavaJe I both supervised and took part in software performance testing and analysis to maximize execution speed and minimize the memory footprint of the SavaJe OS. III. PERFORMANCE ANALYSIS OF UNITED STATES PATENT NO. 5,966,702 A. Introduction 12. I performed experiments to estimate the benefits to Android from using the functionality that Oracle accuses of infringing the ’702 patent, including disabling that functionality in Android. 13. The baseline code for these experiments was the Froyo release of Android, pulled from the public Google git repository as follows repo init –u git://android.git.kernel.org/platform/manifest.git –b froyo repo sync 14. Modifications (as detailed below) were made to the source in the local repository to implement the experiments. 2 to simply allow duplicate constant pool entries to accumulate without widespread modifications to the way in which the dx tool is architected. To get around this, I forced the creation of duplicate entries and made each duplicate unique by inserting a unique number into the value of the duplicate. For example, the type “Ljava/lang/String;” could be duplicated as “Ljava/lang/String123;”. The number is made unique by incrementing it each time a duplicate is created within a specific section of the constant pool. Since this process lengthens the string and therefore inserts extra bytes into the generated dex file, I modified the code to count the number of bytes added so that they could be subtracted from the final file size to get more accurate results. 21. I made this modification to the following classes, each of which represents one of the five sections of the constant pool: com.android.dx.dex.file.FieldIdsSection com.android.dx.dex.file.MethodIdsSection com.android.dx.dex.file.ProtoIdsSection com.android.dx.dex.file.StringIdsSection com.android.dx.dex.file.TypeIdsSection 22. Two points should be noted about this approach. Firstly, the different sections of the constant pool are not completely independent from each other. For example, creating a duplicate type “Ljava/lang/Object2;” causes an additional string constant “L/java/lang/Object2;” to be created as well. If the experiment is carried out in a simplistic way where all five of the constant pool sections are “re-duplicated” at the same time, then because of the renaming, duplicates of duplicates are created, inflating the total number of constant pool entries and thus the final dex file size. The results shown below demonstrate this problem. To avoid it, I modified the code so that I could individually control the duplicate creation for each section of the constant pool. I ran the modified dx tool 5 times for each input jar, creating duplicate entries for only one section of the constant pool each time. The estimated final dex file size is then derived by adding up the additions caused by the duplicate creation for each part of the constant pool. 23. Secondly, consider the fact that the input to the dx tool is a set of compiled Java classes. Within a single class, there will frequently be multiple references to a single constant 5 pool entry. Within the code of the dx tool, at the point where a constant pool entry is being added to the TreeMap, this context is lost, and so there is a possibility that creating duplicate entries in the way described will create duplicates that do not exist in the input Java class files. Rectifying this would have required significant modifications to the dx source code. 24. These two points mean that the results gained by experiment 1 can be regarded as an “upper bound estimate” of the dex file size in the absence of duplicate constant removal. 25. Experiment 1 was repeated on three different jar files representing popular benchmarking applications, and also on the jar file containing the dx tool itself, as an example of a complex application. F. Source Code – Experiment 2 26. The code used to calculate the size of the Java byte code contained in one or more Java class files is contained in Appendix B. No modifications were made to Android source code for this experiment. 27. Experiment 2 was repeated on the same jars files as experiment 1, and also on the jar for the dx tool itself, as an example of a larger and more complex application. G. Source Code – Experiment 3 28. The perl script used to extract information from the dexdump files is contained in Appendix C. No modifications were made to Android source code for this experiment. 29. The perl script takes a set of file names as arguments. Each file is examined in 30. The output of the perl script is data in CSV format. This was chosen to make it turn. easy to import the results into a spreadsheet where calculations could more easily be performed. 31. The basic approach of the perl program is to count the number of times each field, method, type and string constant is used, and then estimate the additional size of the dex file if the constants were duplicated rather than being referenced multiple times. 6

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?