TRILLER EXHIBIT 1017-001
`
`(12) United States Patent
`Czajkowski
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,567,974 B1
`May 20, 2003
`
`USOO6567974B1
`
`(54) SMALL MEMORY FOOTPRINT SYSTEM
`AND METHOD FOR SEPARATING
`APPLICATIONS WITHNA SINGLE
`VIRTUAL MACHINE
`(75) Inventor: Grzegorz J. Czajkowski, Mountain
`View, CA (US)
`(73) Assignee: Sun Microsystems, Inc., Santa Clara,
`CA (US)
`Subj
`y disclai
`h
`f thi
`ubject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`* Y Not
`Otice:
`
`(21) Appl. No.: 09/513,291
`(22) Filed:
`Feb. 25, 2000
`(51) Int. Cl. .............................. G06F 9/45; G06F 9/44
`(52) U.S. Cl. ....................... 717/151; 717/127; 717/118;
`717/161
`(58) Field of Search ................................. 717/151-158,
`717/159-161, 121, 118
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,924.098 A * 7/1999 Kluge ........................ 707/100
`5,946,487 A * 8/1999 Dangelo ...
`... 717/148
`6,066,181 A * 5/2000 DeMaster .....
`... 717/148
`6,108,754 A * 8/2000 Lindholm .....
`... 711/122
`6,138.238 A * 10/2000 Scheifler et al. .....
`... 713/200
`6,141,794. A * 10/2000 Dice et al. ...........
`... 717/118
`6,321,298 B1 * 11/2001 Hubis ...........
`... 711/124
`6,345,313 B1 * 2/2002 Lindholm .....
`... 709/315
`6,374,286 B1 * 4/2002 Gee et al. .....
`... 709/108
`6,453,460 B1 * 9/2002 Keyes .......
`... 717/108
`OTHER PUBLICATIONS
`Bogda et al. Removing Unnecessary Synchronization in
`Java. ACM. 1999. pp. 35–46.*
`Dinning. A Survey of Synchronization Methods for Parallel
`Computers. IEEE. 1989. pp. 66–77.*
`Gardner et al. Performance of Algorithms for Sheduling
`Real-Time Systems with Overrun and Overload. IEEE.
`1999. pp. 287–296.*
`
`
`
`Schneider. Cache and Pipeline Sensitive Fixed Priority
`Scheduling for Preemptive Real-Time Systems. IEEE.
`2000. pp. 195-204.*
`Co-pending application Ser. No. 10/123,702, filed Apr. 16,
`2002.
`Co-pending application Ser. No. 09/513,292, filed Feb. 25,
`2002.
`
`* cited by examiner
`
`Primary Examiner-Gregory Morse
`ASSistant Examiner Wei Zhen
`(74) Attorney, Agent, or Firm Meyertons Hood Kivlin
`Kowert & Goetzel, P.C.; B. Noél Kivlin
`(57)
`ABSTRACT
`A System and method for isolating the execution of a
`plurality of applications. The applications may utilize or
`share one or more “original” classes. Only one copy of each
`original class is maintained, regardless of how many appli
`cations utilize it. Static fields are extracted from the original
`classes. A separate copy of the Static fields is created for each
`of the utilizing applications. A Static field class which
`includes instance fields corresponding to the Static fields
`may be created, wherein each instance of the Static field
`class corresponds to one of the utilizing applications. Access
`methods for the one or more Static fields may be created,
`wherein the access methods are operable to access the
`corresponding Separate copy of the Static fields based upon
`the identity of the utilizing application. A Single access
`methods class may be created for each original class,
`wherein the Single access methods class includes the acceSS
`methods for accessing the extracted fields from the original
`class. The method and System may be optimized by exempt
`ing from extraction Static fields that are classified as Secure
`for utilization by the plurality of applications without inter
`application interference. The Secure Set of Static fields may
`include final Static fields of primitive types, final Static
`Strings, immutable arrays of primitive types, and/or other
`appropriate fields.
`
`30 Claims, 11 Drawing Sheets
`
`{riginal Class
`702
`
`Static Fields
`704
`
`Instance Fields
`
`70s
`
`Methods
`708
`
`Static Fields Class
`
`Static stance
`Fields
`
`Static instance Fields Access Class
`716
`--
`Static Instance
`Field Access
`Methods
`718
`
`S.
`
`Modified Original Class
`702a
`2
`Instance Fields
`706
`Methods
`708
`
`

`

`TRILLER EXHIBIT 1017-002
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 1 of 11
`
`US 6,567,974 B1
`
`
`
`

`

`U.S. Patent
`
`May20, 2003
`
`Sheet 2 of 11
`
`US 6,567,974 B1
`
`esegBaer
`
`gbly
`
`uoBaer
`
`soeaer
`
`eBuoBAer
`
`SOJ9]/]/e8Ws
`
`BuoBAer
`
`SOdo}s0q
`
`BuOBAL
`
`JOSMOlg
`
`soeaer
`
`Ble
`
`alempley
`
`POL?
`
`
`
`aulyoey\JENUIABaer
`
`ccc
`
`
`
`soepe}u|Bulmod
`
`022
`
`Jojdepy
`
`9912
`
`Jajdepy
`
`q9l¢é
`
`aempley
`
`2012
`
`QuemMpleH
`
`GObe
`
`Jajdepy
`
`EQLZ
`
`JOSmolg
`
`ve
`
`SO
`
`eche
`
`aJeMpPJeH
`
`BOL¢
`
`
`
`
`
`(sjaiddyBuipnjoul)suoneoyddy
`
`
`
`VET(S)IdvVJEUIO
`
`OES(S)IdVUOIsUa}xyprepue}sSeAer
`
`
`
`922(S)idv
`
`9e¢
`
`
`
`CLESBSSEIDJOUIO
`
`82SeSse|DUOISUa}Xypuepuej}SeAer
`
`
`
`
`TcSEsSse|ysegeAer
`
`TRILLER EXHIBIT 1017-003
`
`

`

`TRILLER EXHIBIT 1017-004
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 3 of 11
`
`US 6,567,974 B1
`
`Application
`310
`
`
`
`Application
`320
`
`Application
`Class
`304
`
`± - - - - • • • • • • • • • • • • • • • • • • • • • • • • • • • = = = = = = - - - - - - - - - - • • • • • • • • • • • • • • • • • • = = = = = = = • • • • • • • • • • • • • • • •
`
`Static Fields
`
`System Class
`3O8
`
`

`

`TRILLER EXHIBIT 1017-005
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 4 of 11
`
`US 6,567,974 B1
`
`Application
`310
`
`
`
`Application
`320
`
`Application Class
`
`304b.
`
`Static Fields
`
`System Class
`308
`
`Fig. 4
`
`

`

`TRILLER EXHIBIT 1017-006
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 5 of 11
`
`US 6,567,974 B1
`
`Application
`320
`
`Instance
`Fields
`5O2b
`
`Static
`Instance
`
`Application
`
`Fig. 5
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`TRILLER EXHIBIT 1017-007
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 6 of 11
`
`US 6,567,974 B1
`
`
`
`Extract Static Fields From
`Original Class
`602
`
`Create New Static Instance Field Class
`604
`
`Create New Static Instance Field
`ACCess Class
`608
`
`Fig. 6
`
`

`

`TRILLER EXHIBIT 1017-008
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 7 of 11
`
`US 6,567,974 B1
`
`
`
`
`
`
`
`
`
`
`
`

`

`TRILLER EXHIBIT 1017-009
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 8 of 11
`
`US 6,567,974 B1
`
`class Counter {
`static int counter;
`
`static {
`Counter = 0;
`}
`static void add(int val) {
`counter = counter + val;
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Original Class
`802
`
`Fig. 8
`
`class Counter {
`static void hiddenSinitializer() {
`CounterSaMethods.putScnt(0);
`}
`static {hiddenSinitializer(); }
`static void add(int val) {
`int timp =
`CounterSaMethods.getScnt();
`tmp += val;
`CounterSaMethods.putScnt(tmp);
`
`
`
`
`
`
`
`
`
`
`
`
`
`class CounterSsFields {
`int Counter,
`
`class CounterSaMethods {
`static CounterSsFieldssfArr =
`new CounterSsFields(MAX APPS):
`static CounterSsFields getSFields() {
`int id = Thread.currentApplcd();
`CounterSsFields sfields = sfArrid);
`if (sFields == null) {
`sFields = new CounterSsFields();
`sfArrid = sFields;
`Counter.hiddenSinitializer();
`returnsfields;
`
`static int getScnt() {
`return getSFields().counter;
`}
`static void putScnt(int val) {
`getSFields().counter = val;
`}
`}
`
`
`
`Generated Classes
`804
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`TRILLER EXHIBIT 1017-0010
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 9 of 11
`
`US 6,567,974 B1
`
`
`
`Monitor
`
`Static Synchronized
`void foo() {
`
`Synchronized Method
`908
`
`Fig. 9
`
`

`

`TRILLER EXHIBIT 1017-0011
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 10 of 11
`
`US 6,567,974 B1
`
`
`
`
`
`Monitor
`91Ob
`
`static void foo() {
`Synchronized (sfield) {
`{...}
`
`}
`
`
`
`
`
`Static Method With Wrapped
`Synchronized Field Class
`1008
`
`Fig. 10
`
`

`

`TRILLER EXHIBIT 1017-0012
`
`U.S. Patent
`
`May 20, 2003
`
`Sheet 11 of 11
`
`US 6,567,974 B1
`
`
`
`

`

`TRILLER EXHIBIT 1017-0013
`
`US 6,567,974 B1
`
`1
`SMALL MEMORY FOOTPRINT SYSTEM
`AND METHOD FOR SEPARATING
`APPLICATIONS WITHNA SINGLE
`VIRTUAL MACHINE
`
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention relates generally to computer Soft
`ware. More particularly, the present invention relates to the
`efficient isolation of applications executing concurrently in
`a multi-processing environment.
`2. Description of the Relevant Art
`The growing popularity of the platform-independent pro
`gramming language Java" has brought about an increased
`need for executing multiple Java' applications co-located
`on the same computer. Ideally, Such applications should be
`protected from one another. In other words, an application
`should not be able to corrupt the data of another, and the
`application should not be able to prevent another application
`from performing its activities. At the same time, marginal
`Systems resources needed to Start new Java" applications
`should be as small as possible so that the number of
`concurrently executing applications can be as high as poS
`sible.
`One approach to Java" multiprocessing is to rely on the
`operating System (OS) for protection. Typically, this means
`running multiple copies of the JavaTM Virtual Machine
`(JVM), one per application, starting each application in a
`Separate copy of the JVM, which effectively is spawning a
`new operating System process for each application. This
`provides a strong process-level separation in that applica
`tions are totally isolated from one another (although they can
`communicate, for instance, via Sockets, RMI, etc), but uses
`large amounts of resources in terms of Virtual memory and
`Startup time, and makes inter-application communication
`expensive. In addition, this approach tends to Scale poorly.
`A project at the University of Utah resulted in two variants
`of JavaTM operating systems which demonstrate how a
`process model can be implemented in Java TM and how an
`underlying OS protection can be exploited for JavaTM mul
`tiprocessing. See Back, G., Tullmann, P., Stoller, L., Hsieh,
`W., and Lepreau, J., Java Operating System.S. Design and
`Implementation, Technical Report UUCS-98-015, Depart
`ment of Computer Science, University of Utah, August
`1998. The first system, GVM, is structured much like a
`monolithic kernel and focuses on complete resource isola
`tion between processes and on comprehensive control over
`resources. A GVM proceSS comprises a class loader-based
`name Space, a heap, and a Set of threads in that heap. In
`addition to their own heaps, all processes have access to a
`Special, shared System heap. For every heap, GVM tracks all
`references leading to other heaps and all references pointing
`into it. This information is used to implement a form of
`distributed garbage collection. The CPU management in
`GVM combines CPU inheritance scheduling with the hier
`archy introduced by Java" thread groups: thread groups
`within processes may hierarchically Schedule the threads
`belonging to them.
`A Second variant of a Java" operating System developed
`at the University of Utah, Alta, closely models a micro
`kernel model with nested processes, in which a parent
`proceSS can manage all resources available to child pro
`cesses. Memory management is Supported explicitly,
`through a simple allocator-pays Scheme. The garbage col
`lector credits the owning process when an object is eventu
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`ally reclaimed. Because Alta allows cross-process
`references, any existing objects are logically added into the
`parent memory. This makes the parent process responsible
`for making Sure that cross-proceSS references are not created
`if full memory reclamation is necessary upon process ter
`mination. Both GVM and Alta are implemented as consid
`erable modifications to the JVM. Both systems support
`Strong proceSS models: each can limit the resource consump
`tion of processes, but still permit processes to share data
`directly when necessary.
`Advocates of proceSS-based Java" application Separation
`point out that a failure of one process terminates only this
`particular application and may potentially affect other appli
`cations only through an absence of Service. Common wis
`dom States that processes are more reliable than implemen
`tations of JVMs. This reasoning implies that executing
`multiple applications in a Single copy of the JVM puts them
`at a risk of being abruptly terminated because another
`application triggers an action, which will cause the whole
`JVM to go down. However, it does not necessarily have to
`be SO. Processes still execute on top of an underlying
`operating System, and no major operating System kernel is
`guaranteed to be bug-free. Ultimately, one trusts Software,
`whether it is an OS or a runtime of a Safe language. The
`reliability issues of the JavaTM platform and of an OS kernel
`are essentially the same. Moreover, Safe language has leSS
`potential for crashing because of Software problems.
`The SPIN extensible operating system, written almost
`entirely in a safe subset of Modula-3, utilizes both hardware
`and Software protection. See Bershad, B., Savage, S.,
`Pardyak, P., Sirer, E., Fiuczynski, M., Becker, D., Eggers, S.,
`and Chambers, C., Extensibility, Safety and Performance in
`the SPIN Operating System, 15' ACM Symposium on
`Operating Systems Principles, Copper Mountain, Colo.,
`December 1995. Hardware protection is used to isolate
`address Spaces, Software protection protects the OS kernel
`from extensions. However, it is the view of the SPIN authors
`that protection is a Software issue, and that with a well
`designed inter-application isolation in a Safe language, there
`should be no need for hardware protection. See Bershad, B.,
`Savage, S., Pardyak, P., Becker, D., Fiuczynski, M., Sirer,
`E., Protection is a Software Issue, 5" Workshop on Hot
`Topics in Operating Systems, Orcas Island, Wash., May
`1995.
`An alternative approach is to execute applications in the
`Same instance of the JVM. Typically, each application is
`loaded by a separate class loader. See Liang S., and Bracha,
`G., Dynamic Class Loading in the Java Virtual Machine, In
`Proceedings of ACMOOPSLA'98, Vancouver, BC, Canada,
`October 1998. This code replication is especially wasteful in
`the presence of just-in-time compilers (JITs). Currently
`available class loading mechanisms Separately compile and
`Separately Store the JITed code of each loaded class, regard
`less of whether the class has already been loaded by another
`application or not. This can easily lead to Significant
`memory footprints, Since, on the average, a byte of bytecode
`may translate into about five bytes of native code, where the
`term bytecode refers to compiled. JavaTM code. See Cramer,
`T., Friedman, R., Miller, T., Seberger, D., Wilson, R., and
`Wolczko, M., Compiling Java Just in Time, IEEE Micro,
`May/June 1997. Combined with the safety of the language,
`this approach leads to Systems where applications are mostly
`isolated from one another. The place where the isolation
`breaks is the interaction of applications through Static fields
`and Static Synchronized methods of System classes (as they
`are not Subject to per-application replication).
`A simple example of a Java" multiprocessing utilizing
`class loaders is the class library Echidna. With a reasonable
`
`

`

`TRILLER EXHIBIT 1017-0014
`
`3
`degree of transparency, it allows multiple applications to run
`inside a single JVM. Applications can cleanly dispose of
`important resources when they are killed. For example,
`when a proceSS is killed all its windows are automatically
`removed.
`A more complex example of a class loader based
`approach to application protection is the J-Kernel. See
`Hawblitzel, C., Chang, C-C., Czajkowski, G., Hu, D. and
`von Eicken, T., Implementing Multiple Protection Domains
`in Java, In Proceedings of USENIX Annual Conference,
`New Orleans, La., June 1998. The J-Kernel adds protection
`domains to Java and makes a strong distinction between
`objects that can be shared between tasks and objects that are
`confined to a Single task. Each domain has its own class
`loader. The system, written as a portable JavaTM library,
`provides mechanisms for clean domain termination (e.g., no
`memory allocated by the task is “left over” after it is
`terminated) and inter-application communication
`(performed via deep object copies or methods arguments
`and return values).
`Balfanz and Gong designed a multiprocessing JVM in
`order to explore the use of the Java TM security architecture
`to protect applications from each other. See Balfanz, D., and
`Gong, L., Experience with Secure Multi-Processing in Java,
`Technical Report 560-97, Department of Computer Science,
`Princeton University, September, 1997. The proposed exten
`Sions enhance the Standard JVM So that it can Support
`multiprocessing. An important part of the work is clear
`identification of several areas of the JDK that assume a
`Single-application model.
`Two current trends cast doubt on the future usefulness of
`these two approaches to Java" multiprocessing. On one end
`of the computing power spectrum, high-end high throughput
`Servers have to deal with large Volumes of concurrently
`executing Java" programs. Increasingly, in addition to
`traditional, large and Self-contained applications, Smaller
`entities (e.g., applets, servlets, and JavaBeans"
`components) are part of the computation System. The
`OS-based approach to Java" multiprocessing is often unac
`ceptable in these Settings Since it requires allocating large
`amounts of System resources for Starting many copies of the
`JVM and thus tends to scale very poorly. Using class loaders
`has the potential for better Scaling performance but it also
`wastes resources on replicating application code when more
`than one application executes the same program. Indicated
`isolation inconsistencies make this approach unsafe in gen
`eral.
`On the other end of the spectrum, Small-footprint JVMs
`are emerging which target Small devices. They typically lack
`many features available in fully blown implementations of
`the JVM available on general-purpose computers. An
`example is the K Virtual Machine (KVM) from Sun
`Microsystems, Inc. Since the KVM specification does not
`require that its implementations provide class loaders, mul
`tiprocessing in a Single instance of the KVM is possible only
`when all applications are trusted and guaranteed not to
`interfere with one another. ProceSS-based multiprocessing
`using KVM is also problematic since Small devices for
`which it is meant do not necessarily provide a process model
`with adequate Strong application Separation guarantees.
`Another example of a Java TM-based system without an
`underlying OS process abstraction is JavaOSTM.
`AS Stated above, Systems offering Java" multiprocessing
`can be classified as either based on an underlying operating
`System, which typically means running one process for each
`Java" application, or as using class loaders. However, using
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,567,974 B1
`
`4
`operating System processes is expensive, Scales poorly, and
`does not fully exploit the protection features inherent in a
`Safe language. Class loaders replicate application code,
`obscure the type System, and non-uniformly treat “trusted’
`and “untrusted’ classes, which leads to Subtle but neverthe
`less potentially harmful forms of undesirable inter
`application interaction.
`One way to achieve multi-tasking in a single processing
`Space is through the use of threads. Multithreaded applica
`tions may be written in languages Such as C and C++, but
`Writing multithreaded C and C++ applications may be
`difficult. Furthermore, there are no assurances that third
`party libraries are thread-safe. AS used herein, “thread-Safe”
`means that a given library function is implemented in Such
`a manner that it can be safely executed by multiple concur
`rent threads of execution. Thread-safe programming often
`relies on “locks” or “monitors,” which are used synony
`mously herein. One major problem with explicitly pro
`grammed thread Support is that acquiring and releasing the
`locks needed at the right time tends to be difficult. For
`example, if a method returns prematurely, or if an exception
`is raised, and a related lock has not been released, deadlock
`usually results.
`The JavaTM Language provides some built-in support for
`threads. The JavaTM library provides a Thread class that
`Supports a rich collection of methods to start a thread, run a
`thread, Stop a thread, and check on a thread's Status. This
`built-in support for threads provides JavaTM programmers
`with a powerful tool to improve interactive performance of
`graphical applications. If an application desires to run ani
`mations and play music while Scrolling the page and down
`loading a text file from a Server, for example, then multi
`threading provides fast, lightweight concurrency within a
`Single process Space. Threads are Sometimes referred to as
`lightweight processes or execution contexts.
`JavaTM thread support includes a sophisticated set of
`Synchronization primitives based on the widely used moni
`tor and condition variable paradigm introduced twenty years
`ago by C. A. R. Hoare and implemented in a production
`setting in Xerox PARC's Cedar/Mesa system. Java TM Sup
`ports multithreading at the language (Syntactic) level and via
`Support from its run-time System and thread objects. At the
`language level, Java"M specifies that methods within a class
`that are declared "Synchronized” do not run concurrently.
`Such methods run under control of monitors to ensure that
`variables remain in a consistent State. Every class and
`instantiated object has its own monitor that comes into play
`if required. When a synchronized method is entered, it
`acquires a monitor on the current object. The monitor
`precludes any other Synchronized methods in that object
`from running. When a Synchronized method returns by any
`means, its monitor is released. Other Synchronized methods
`within the same object are then free to run.
`While other systems have provided facilities for multi
`threading (usually via “lightweight process' libraries),
`building multithreading Support into the language as Java"
`has done provides the programmer with a much more
`powerful tool for easily creating thread-Safe multithreaded
`classes. Other benefits of multithreading are better interac
`tive responsiveness and real-time behavior.
`Nonetheless, the built-in support for multithreading in the
`Java" Language has its drawbacks. For example, applica
`tions may contend for the execution of a Static Synchronized
`method. A Synchronized method acquires a monitor lock
`before it executes, and a Static method is invoked without
`reference to a particular object. For a Static Synchronized
`
`

`

`TRILLER EXHIBIT 1017-0015
`
`S
`method, the lock associated with the class object for the
`methods class is used. One application may acquire a lock
`on a Static Synchronized method and refuse to release the
`lock, thereby preventing other applications from invoking
`the method.
`Therefore, an improved system and method for efficiently
`isolating applications within a single virtual machine are
`desired.
`
`SUMMARY OF THE INVENTION
`The problems outlined above are in large part solved by
`various embodiments of a System and method for isolating
`the execution of a plurality of applications as disclosed
`herein. The applications may include applets, Servlets, oper
`ating System Services, components, JavaBeans", or other
`Suitable executable units or programs. “Application' and
`“program” are here in used Synonymously. In one
`embodiment, the applications are executable in a platform
`independent programming environment Such as the Java"
`environment. In one embodiment, the applications are
`executable on a single instance of a virtual machine, Such as
`a JavaTM Virtual Machine, which is implemented in accor
`dance with a platform-independent Virtual machine
`specification, such as the JavaTM Virtual Machine Specifi
`cation. The plurality of applications may utilize one or more
`“original' classes. In other words, the original classes may
`be shared by a plurality of applications. The general
`approach taken by the System and method as disclosed
`herein is to create new classes to replace the original classes
`in order to isolate the execution of the applications, Such that
`different applications cannot typically access the same Static
`fields. In one embodiment, only one copy of each original
`class is maintained, regardless of how many applications
`utilize it. Classes are transparently and automatically
`modified, So that each application has a separate copy of its
`static fields. This provides for a minimal collective footprint,
`with Strong application isolation. In addition, this allows
`class loaders to be removed from the type System.
`In one embodiment, one or more Static fields are extracted
`from one or more original classes utilized by any of the
`plurality of applications, wherein each of the one or more
`original classes includes at least one Static field. In one
`embodiment, a separate copy of the one or more Static fields
`is created for each of the plurality of applications, wherein
`each of the Separate copies corresponds to one of the
`plurality of applications. Creating the Separate copy of the
`one or more Static fields may include creating a Static field
`class which includes instance fields corresponding to the one
`or more Static fields, wherein each instance of the Static field
`class corresponds to one of the plurality of applications. In
`one embodiment, one or more acceSS methods for the one or
`more Static fields may be created. The acceSS methods are
`operable to access the corresponding Separate copy of the
`one or more Static fields based upon the identity of the
`utilizing or calling application. Creating access methods for
`the one or more Static fields may include creating a single
`access methods class for each original class which includes
`the access methods for accessing the extracted fields from
`the original class.
`In one embodiment, the method for isolating the execu
`tion of the applications is transparent to the utilizing appli
`cations. In various embodiments, the extraction of the Static
`fields, creation of the Separate copies of the Static fields, and
`creation of the acceSS methods may be performed at run
`time or at compilation, and at the Source level or the
`bytecode level. In a further embodiment, the method may be
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,567,974 B1
`
`6
`performed upon Structures rather than classes, Such as in a
`programming environment that is not object-oriented.
`Further optimizations to the method for isolating the
`execution of the applications may be performed. A set of
`Static fields may be classified as Secure for utilization by the
`plurality of applications without inter-application interfer
`ence. The Secure Set of Static fields may include final Static
`fields of primitive types, final Static Strings, immutable
`arrays of primitive types, and/or other appropriate fields.
`The secure set of static fields may then be preserved within
`the one or more classes. In other words, the Set of Static fields
`may be exempted from the one or more Static fields which
`are extracted from the one or more classes.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`Other objects and advantages of the invention will
`become apparent upon reading the following detailed
`description and upon reference to the accompanying draw
`ings in which:
`FIG. 1 is an illustration of a typical computer System
`architecture which is Suitable for implementing various
`embodiments.
`FIG. 2 is an illustration of a Java TM Platform architecture
`which is Suitable for implementing various embodiments.
`FIGS. 3 through 5 are illustrations of class sharing
`between two applications according to various embodi
`mentS.
`FIG. 6 is an illustration of Static field Separation according
`to one embodiment.
`FIG. 7 is a flowchart of static field separation according
`to one embodiment.
`FIG. 8 illustrates an example of static field separation
`according to one embodiment.
`FIG. 9 illustrates the contention of multiple applications
`for a Synchronized Static method in a multi-threaded, multi
`application proceSS Space.
`FIGS. 10 and 11 illustrate the system and method of
`isolating Static Synchronized methods in a multi-threaded,
`multi-application environment according to one embodi
`ment.
`While the invention is susceptible to various modifica
`tions and alternative forms, specific embodiments thereof
`are shown by way of example in the drawings and will
`herein be described in detail. It should be understood,
`however, that the drawing and detailed description thereto
`are not intended to limit the invention to the particular form
`disclosed, but on the contrary, the intention is to cover all
`modifications, equivalents and alternatives falling within the
`Spirit and Scope of the present invention as defined by the
`appended claims.
`DETAILED DESCRIPTION OF SEVERAL
`EMBODIMENTS
`FIG. 1: A Typical Computer System
`Turning now to the drawings, FIG. 1 is an illustration of
`a typical, general-purpose computer System 100 which is
`Suitable for implementing the System and method for appli
`cation isolation as disclosed herein. AS discussed with
`reference to FIGS. 6 through 8, the system and method for
`application isolation may include providing multiple copies
`of Static fields to isolate the execution of the applications,
`Such that different applications cannot typically access the
`Same Static field.
`The computer system 100 includes at least one central
`processing unit (CPU) or processor 102. The CPU 102 is
`
`

`

`TRILLER EXHIBIT 1017-0016
`
`US 6,567,974 B1
`
`15
`
`25
`
`35
`
`40
`
`7
`coupled to a memory 104 and a read-only memory (ROM)
`106. The memory 104 is representative of various types of
`possible memory media: for example, hard disk Storage,
`floppy disk Storage, removable disk Storage, or random
`access memory (RAM). The terms “memory” and “memory
`medium' may include an installation medium, e.g., a
`CD-ROM or floppy disk, a computer system memory such
`as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a
`non-volatile memory Such as a magnetic media, e.g., a hard
`drive, or optical Storage. The memory medium may include
`other types of memory as well, or combinations thereof. In
`addition, the memory medium may be located in a first
`computer in which the programs are executed, or may be
`located in a Second different computer which connects to the
`first computer over a network. In the latter instance, the
`Second computer provides the program instructions to the
`first computer for execution.
`As shown in FIG. 1, typically the memory 104 permits
`two-way access: it is readable and writable. The ROM 106,
`on the other hand, is readable but not writable. The memory
`104 and/or ROM 106 may store instructions and/or data
`which implement all or part of the System and method
`described in detail herein, and the memory 104 and/or ROM
`106 may be utilized to install the instructions and/or data. In
`various embodiments, the computer system 100 may take
`various forms, including a personal computer System, desk
`top computer, laptop computer, palmtop computer, main
`frame computer System, workStation, network appliance,
`network computer, Internet appliance, personal digital assis
`tant (PDA), embedded device, Smart phone, television
`System, or other Suitable device. In general, the term “com
`puter System' can be broadly defined to encompass any
`device having a processor which executes instructions from
`a memory medium.
`The CPU 102 may be coupled to a network 108. The
`network 108 is representative of various types of possible
`networks: for example, a local area network (LAN), wide
`area network (WAN), or the Internet. The system and
`method for application isolation in accordance as disclosed
`herein may therefore be implemented on a plurality of
`heterogeneous or homogeneous networked computer Sys
`tems 100 through one or more networks 108. The CPU 102
`may acquire instructions and/or data for implementing Sys
`tem and method for application isolation in accordance as
`disclosed herein over the network 108.
`Through an input/output bus 110, the CPU 102 may also
`coupled to one or more input/output devices that may
`include, but are not limited to, Video monitors or other
`displays, track balls, mice, keyboards, microphones, touch
`Sensitive displays, magnetic or paper tape readers, tablets,
`Styluses, voice recognizers, handwriting recognizers,
`printers, plotters, Scanners, and any other devices for input
`and/or output. The CPU 102 may acquire instructions and/or
`data for implementing the System and method for applica
`tion isolation as disclosed herein through the input/output
`buS 110.
`The computer system 100 is operable to execute one or
`more computer programs. The computer programs may
`comprise operating System or other System Software, appli
`cation Software, utility Software, Java" applets, and/or any