United States Patent
`
`[19]
`
`[11] Patent Number:
`
`5,815,718
`
`Tock
`[45] Date of Patent:
`Sep. 29, 1998
`
`
`USOOS815718A
`
`[54] METHOD AND SYSTEM FOR LOADING
`CLASSES IN READ-ONLY MEMORY
`Inventor: Theron DI Tuck Sunnyvale Calif.
`
`[75]
`
`oran PUBLICATIONS
`“Java Intermediate Bytecodes”; J. Gosling; 1995 ACM
`SIGPLAN Workshop on Intermediate Representations; pp.
`111—118.
`
`[73] Assignee: Sun Microsystems, Inc., Mountain
`View, Calif.
`
`.
`..
`,
`[21] Appl No . 655 474
`
`[22]
`
`Filed:
`
`May 30, 1996
`
`Int. Cl.6 ........................................................ G06F 9/45
`[51]
`[52] US. Cl.
`......................... .. 395/705; 395/710; 395/685
`[58] Field of Search ................................... .. 395/701, 702,
`395/710, 651, 652, 685, 705, 708
`
`[56]
`
`References Cited
`
`Us. PATENT DOCUMENTS
`9/1991 Tenny et a1.
`.......................... .. 364/200
`395/700
`4/1994 Tenny et a1.
`..
`395/700
`11/1994 Nakano et a1.
`.. 395/712
`1/1997 Bunnell et a1.
`31,1997 Palay et al.
`395/710
`9/1997 Baner .......... u
`345/334
`9/1997 Shipman et a1.
`......................u 395/700
`
`
`
`5,051,893
`5,303,380
`5,369,766
`5,594,903
`5’613’120
`5 664 128
`5:671:413
`
`FOREIGN PATENT DOCUMENTS
`
`2 242 293
`
`9/1991 United Kingdom .
`
`20 Claims, 12 Drawing Sheets
`
`300
`
`Per Class
`.— ————————————————— - — —.
`
`Source Code
`
`126
`
`Compiler
`
`122
`
`
`
`Class File
`
`
`
`Class Libraries I
`
`131
`
`
`
`
`
`
`
`
`180
`
`Hash
`Table
`
`Primary Examiner—Emanuel Todd Voeltz
`Assistant Examiner—Kakali Chaki
`Attorney, Agent, or Firm—Gary S. Williams; Flehr Hohbach
`Test Albritton & Herbert LIP
`[57]
`ABSTRACT
`A method and s stem for
`rovidin an executable module
`having an addm; Space f0}; storinggpmgram data that is to
`reside in a read_0nly Storage medium and an address Space
`for storing program data that is to reside in a random access
`memory is herein described. The executable module repre-
`sents Java classes that are structured for dynamic class
`loading. A static class loader is usedto modify the class
`structure to accommodate static loading. The static class
`loader also identifies methods that contain unresolved'sym-
`bolic references and data that varies during the execution of
`the modme. These methods and data are identified in order
`to place them in the address space that resides in the random
`access memory. The static loader is beneficial in a distrib-
`uted computing enVironment haVing a client computer that
`has little or no secondary storage thereby requiring appli-
`cations to run entirely in random access memory. By utiliz-
`ing a read-only memory to store statically loadable classes,
`the random access memory is left available for other uses.
`
`
`
`Offline Class \ 132
`Loader
`v
`Updated Class File and
`Constant Pool
`
`\ 302
`
`
`
`134
`
`304
`
`\136
`
`
`
`306
`ROM portion
`RAM portion
`Preloadable executable module
`
`1
`
`Apple v. Realtime
`Proceeding No. |PR2016-01365
`APPLE 1019
`
`Apple v. Realtime
`Proceeding No. IPR2016-01365
`APPLE 1019
`
`1
`
`

`

`
`
`US. Patent
`
`Sep. 29, 1998
`
`Sheet 1 0f 12
`
`5,815,718
`
`118
`
`120
`
`122
`
`124
`
`126
`
`128
`
`‘i 30
`
`131
`
`132
`
`134
`
`136
`
`138
`
`140
`
`142
`
`144
`
`146
`
`100
`\d
`
` 112 Operating System
`
`110
`
`Network Access Procedures
`
`
`Source Code Repository
`
`
`
`
`
`
`Class File Repository
`
`
`Class File
`
`Class Libraries
`
`_ O
`
`ffline Class Loader
`
`
`
`User Interface
`
`Server
`
`fl
`
`116
`
`Communications
`
`Interface
`
`
`Browser
`Runtime Class Loader Mod.
`
`B ecode Verifier Module
`
`HTML Loader Module
`
`Data Files
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Network Interconnectivity
`Switches, etc
`
`1
`
`
`
`Client
`
`
`
`
`
`°
`
`
`
`
`104
`
`FIG. 1
`
`
`
`2
`
`

`

`US. Patent
`
`Scp.29,1998
`
`Sheet 2 0f 12
`
`5,815,718
`
`210
`
`
`
`204
`
`HTML Document Repository
`
`
`
`208
`Browser
`212
`
`
`02
`Operating System
`213
`Network Access Procedures
`214
`
`
`_
`
`
`
`
`
`
`
`
`
`
`
`FIG. 2
`
`
`
`216
`217
`
`226
`
`228
`
`Class File Repository
`
`Class File
`
`206
`
`Communications
`
`Interface
`
`Data Files
`
`Network Interconnectivity
`(Switches, etc)
`
`061
`
`108
`
`
`
`3
`
`

`

`US. Patent
`
`Scp.29,1998
`
`Sheet 3 0f 12
`
`5,815,718
`
`300
`W
`
`Per Class
`,— — — — — - — — _ _ _ . _ _ _ _ _ . _ _ .1
`
`126
`
`122
`
`130
`
`128
`
`Class Libraries I
`
`131
`
`132
`
`
`
`
` x 302
`
`
`
`
`
`134
`
`304
`
`
`
`Object Module
`
`X 136 _
`
`
`ROM portion
`
`RAM portion
`
`306
`
`Preloadable executable module
`
`
`
`
`FIG. 3
`
`ClassFile
`
`Offline Class
`
`Loader
`
`
`
`
`
`Updated Class File and
`Constant Pool
`
`4
`
`

`

`US. Patent
`
`Scp.29,1998
`
`Sheet 4 0f 12
`
`5,815,718
`
`400
`\Q
`
`Class File
`
`Header Info
`
`Constant Pool
`
`Exception Table
`
`FIG. 4
`
`Constant Pool
`
`
`
`J!
`
`402
`
`404
`
`406
`
`408
`
`.‘i-ld
`
`—I
`
`l!
`
`504
`
`506
`
`508
`
`510
`
`512
`
`514
`
`404
`
`W Superclass Name
`No. of fields
`
`No. of string constants
`
`Strin
`I'GC an e
`
`—_
`
`No. of methods
`
`51 1
`
`Method 1 p"
`l
`c ass name
`ptr
`
`— 516
`
`FIG. 5
`
`5
`
`

`

`Scp.29,1998
`
`Sheet 5 of 12
`
`5,815,718
`
`US. Patent
`
`600
`
`I
`
`Class Name
`
`P"
`"I
`ptr
`
`One per Class
`\zx
`I‘ - — _ _ — — - — ‘ _ — — — — _ _ - _ — _ _ — ‘ - ‘ — _ _ _ _ _ _ _ — - — — _ — — - _ I
`I
`Method Block 1
`II
`:
`604
`|
`610608 Method 1
`Class BIOCK
`602 612
`tr
`b teCOde II
`Method
`_5: CA)O 3'1-4- H
`In)I—L
`tr
`Method
`i
`.
`Mam“:
`;
`Field Blocks .
`W 614 I
`—I 61 :
`Field Block n P” I— 618
`
`————.——________.__.._.__.._____._.___.___.__.._..__._______.o
`
`Exception Table
`
`'-0
`
`ptr
`,... .1
`
`620
`
`Constant Pool 624 Map Table626
`
`Exception Table
`
`28
`
`—_
`
`Constant Pool
`
`636
`
`030)AC.)00)
`
`6
`
`

`

`Word 1
`
`0
`
`
`
`
`
`7 8
`
`15 16
`
`23 24
`
`31
`
`
`
`
`
`US. Patent
`
`Sep. 29, 1998
`
`Sheet 6 0f 12
`
`5,815,718
`
`Word 2
`
`FIG. 7
`
`7
`
`

`

`
`
`US. Patent
`
`Sep. 29, 1998
`
`Sheet 7 0f 12
`
`5,815,718
`
`132
`
`\d
`
`For each class file
`Build class data structures
`
`
`
`804
`
`802
`
`Allocate space for hash table
`
`805
`
`
` For each class file
`
`
`Read each entry in the constant pool
`Eliminate duplicate constants
`
`
`
`
`
`806
`
`310
`
`812
`
`814
`
`
`
`815
`
`818
`
`820
`
`822
`
`824
`
`826
`
`828
`
`830
`
`For each class file
`For each string constant
`
`Determine common substrings
`
`For each class file
`
`For each method
`
`For each bytecode
`
`inspect invoke instructions
`
`Count references to constants
`
`l
`
`Mark field blocks that store
`
`fields that are altered by the
`
`b tecodes in RAM storae
`
`FIG. 8A
`
`FIG. 8B
`
`FIG. 8
`
`FIG. 8A
`
`8
`
`

`

`US. Patent
`
`\J‘
`
`Sep. 29, 1998
`
`Sheet 8 0f 12
`
`5,815,718
`
`o
`
`Allocate space for the universal constant
`
`For each method
`
`For each class file
`
`pool and merge constants into it
`
`For each class file
`
`For each method
`
`
`
`
`
`
`
`Pen‘orm flow analysis
`
`Create new method to handle static class
`
`
`
`
`FIG. 8B
`
` 926
`
`
`
`
`
`initializer
`
`linkage instructions indicating
`Insert
`RAM/ROM memory requirements
`
`928
`
`930
`
`Output universal constant pool file,
`an updated class file, and a boot time
`initializer for loading the runtime modifiable
`methods and data into RAM at boot time.
`
`Return
`
`9
`
`

`

`US. Patent
`
`Sep. 29, 1998
`
`Sheet 9 0f 12
`
`5,815,718
`
`804
`
`\r‘
`
`Build class data structures
`
`
`
`1 002 1 004
`
`
`
` 1 006
`
`
`
`
`
`
`
`
`
`
`
`Read header info and allocate
`
`block data structures
`
`Update class block to include
`pointers to block data structures
`
`Allocate space for map table
`
`1 008
`
`Read in constant pool data
`
`Read in method data
`
`
`
`1010
`
`1012
`
`Read in exception table data
`
`Return
`
`FIG. 9
`
`10
`
`10
`
`

`

`US. Patent
`
`Scp.29, 1998
`
`Sheet 10 0f 12
`
`5,815,718
`
`812
`
`W
`
`Eliminate Duplicate Constants
`
`Determine the hash value for
`
`the constant
`
`1102
`
`
`
`Is the hash value in the
`
`hash table?
`
`1108
`
`
`
`1104
`
`
`Update the constant map
`table to reflect the location
`
`of the existin ent
`
`
`
`
`
`
`
`Store hash value and
`
`address in hash table
`
`Return
`
`FIG. 10
`
`11
`
`11
`
`

`

`US. Patent
`
`Scp.29, 1998
`
`Sheet 11 0f 12
`
`5,815,718
`
`826
`
`\1‘
`
`Inspect Invoke Instructions
`
`
`
`Does the bytecode invoke
`an Interface?
`
`1204
`
`
`
`
`
`
`
`
`Does the bytecode invoke
`a method?
`
`Return
`
`Add to the methods name
`
`
`in the constant pool a pointer
`to the method block
`
`Return
`
`FIG. 11
`
`12
`
`12
`
`

`

`US. Patent
`
`Scp.29, 1998
`
`Sheet 12 0f 12
`
`5,815,718
`
`210
`
`RAM Space for dynamically loaded
`applets, classes and data
`
`Copy of Methods and Data
`to be executed from RAM
`
`Copy made by Boot Time
`lnitializer upon power up or
`reboot
`
`
`
`
`
`
`T.
`
`I
`
`..
`
`Methods and Data to be
`
`executed from RAM
`
`Methods and Data to be
`
`executed from ROM
`
`FIG. 12
`
`13
`
`13
`
`

`

`
`
`5,815,718
`
`1
`METHOD AND SYSTEM FOR LOADING
`CLASSES IN READ-ONLY MEMORY
`
`The present invention relates generally to object-oriented
`computer systems having classes that are dynamically
`loaded at runtime, and particularly to a system and method
`for preloading a subset of the classes in a read-only memory.
`BACKGROUND OF THE INVENTION
`
`2
`In an embodiment, a client computer having minimal
`secondary storage utilizes an offline class loader to preload
`a browser in the client’s read—only memory. The browser is
`partitioned into the aforementioned two address spaces. At
`system initialization or power up,
`the random access
`memory portion of the browser is loaded from read-only
`memory into the random access memory. By executing a
`large portion of the browser from read-only memory, the
`browser has additional RAM storage to store information-
`content and executable modules that it can obtain from other
`server computers that the client is in communication with.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Additional objects and features of the invention will be
`more readily apparent from the following detailed descrip-
`tion and appended claims when taken in conjunction with
`the drawings, in which:
`FIG. 1 is a block diagram of a distributed computer
`system.
`FIG. 2 is a block diagram of a client computer in the
`distributed computer system of FIG. 1.
`FIG. 3 is a flow diagram illustrating the processing
`components used to produce the preloadable executable
`module.
`
`10
`
`15
`
`trend in object-oriented programming lan-
`A current
`guages is to extend the functionality of the language to
`accommodate the distribution of dynamic content
`in a
`distributed computing environment. In one such language,
`this is accomplished by dynamically loading classes at
`runtime. A class is a collection of variables and methods that
`model the behavior of an object. By dynamically loading
`classes at runtime, existing applications can add function-
`ality by linking in new classes that reside on any computer
`system within the distributed computing environment.
`In such languages, symbolic references are used to refer ’
`to the class members (i.e., the class” methods and variables).
`When a class is invoked, the dynamic loader determines the
`storage schema for the class and resolves the symbolic
`reference. Such a loading scheme is beneficial when access-
`ing classes that are updated often. However, a limitation of
`such a loading scheme is its dependency on a read/write
`memory device such as a random access memory (RAM). In
`a computing environment that has little or no secondary
`storage (e.g., non-volatile magnetic disk storage), dynamic
`loading of the classes in this manner can quickly use up the
`storage capacity of the RAM. As the capacity of the RAM
`is limited, it is desirable to minimize the amount of RAM
`that is used by an application. Accordingly, there exists a
`need to limit the amount of RAM that is utilized to execute
`
`object-oriented program code having dynamically loadable
`classes.
`
`It would be beneficial to provide a method and system
`which overcomes the deficiencies of the prior art.
`SUMMARY OF THE INVENTION
`
`In summary, this disclosure pertains to an offline class
`loader that is used to produce an executable module whose
`classes are preloaded into memory without requiring runt-
`ime dynamic loading. The executable module, nevertheless,
`contains a class structure that is tailored for runtime dynamic
`loading. Thus, the offline class loader modifies the existing
`class structures to accommodate static loading. However,
`the class structure allows for varying data and methods that
`contain unresolved references. The offline class loader tags
`these methods and data specifying that they are to be stored
`in a random access memory. All other data is stored in a
`read-only memory. At the completion of the static loading
`process, a preloadable executable module is generated that
`contains two addresses spaces. A first address space that
`contains methods having unresolved references and data that
`varies during the execution of the module is loaded in a
`random access memory. The second address space contains
`methods having static loaded classes and constant data
`which is loaded into a read-only memory.
`Apreloadable executable module of this fashion is advan-
`tageous in a distributed computer system having client
`computers with little or no secondary storage. Such client
`computers require applications to run entirely in random
`access memory which quickly turns into a limited resource.
`By utilizing the offline class loader to partition an applica-
`tion into two address spaces, the amount of RAM utilized by
`the preloadable module is minimized.
`
`40
`
`45
`
`60
`
`65
`
`14
`
`/
`
`FIG. 4 illustrates the file layout for a class file.
`FIG. 5 illustrates the file layout for a constant pool.
`FIG. 6 illustrates the class block data structures.
`
`FIG. 7 illustrates an instruction bytecode stream.
`FIG. 8, which is a combination of FIGS. 8A and 8B,
`represents a flow chart of the method used by the oflline
`class loader.
`
`FIG. 9 is a flow chart of the method for building the class
`block data structures.
`
`FIG. 10 is a flow chart of the method for eliminating
`duplicate constants.
`FIG. 11 is a flow chart of the method for converting a
`non-quick instruction format into a quick instruction format.
`FIG. 12 is a block diagram showing the mapping of a
`preloaded application into read-only memory and random-
`aeeess memory and indicating the loading of the portion of
`the methods and data mapped into random-access memory
`by a static class initializer.
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`The method and system described herein utilizes a dis-
`tributed computing environment having a communication
`link that connects at least one server computer and a number
`of client computers. Some of the client computers have little
`or no secondary storage (e.g., non—volatile magnetic disk
`storage) thereby requiring applications to be run entirely
`from random access memory. An application developed in
`the Java programming language is executed on such a client
`computer. Preferably, the application is a browser that is
`used to import Java content, such as Java applets, from one
`or more server computers. Typically,
`the browser is an
`interpreted program module that retrieves Web documents
`utilizing a HyperText Transfer Protocol (HTTP) to access
`one or more Web pages formatted as HyperText Markup
`Language (HTML) documents from a server acting as a Web
`site. The HTML documents are interpreted and presented to
`the user associated with the client computer. Often,
`the
`HTML documents embed applets. An applet is a executable
`module represented as a Java class. The browser loads in the
`applet and its associated classes in order to execute the
`applet.
`
`
`
`14
`
`

`

`5,815,718
`
`4
`In an embodiment, one or more server computers act as
`Web sites containing a repository of HTML documents
`containing Java content or applets. The client computer
`executes a browser that provides a user associated with the
`client computer with access to the HTML documents avail-
`able from the server computer. Referring to FIG. 1, a server
`computer typically includes one or more processors 112, a
`communications interface 116, a user interface 114, and
`memory 110. Memory 110 stores:
`an operating system 118;
`an Internet communications manager program or other
`type of network access procedures 120;
`a compiler 122 for translating source code written in the
`Java programming language into a stream of bytecodes;
`a source code repository 124 including one or more
`source code files 126 containing Java source code;
`a class file repository 128 including one or more class files
`130, and one or more class libraries 131 containing
`class files, each class file containing the data represent-
`ing a particular class;
`an offline class loader 132 which is used to preload a
`certain set of classes; the offline class loader can also be
`referred to as a static class loader;
`an assembler 134 which produces an object file repre-
`senting the class members, class data structures, and
`memory storage indicators in a format that is recog—
`nizable for the linker;
`a linker 136 for determining the memory layout for a set
`of preloaded classes and for resolving all symbolic
`references;
`a browser 138 for use in accessing IITML documents; and
`one or more data files 146 for use by the server.
`The browser can include:
`
`a runtime time class loader module 140, which loads
`classes into a user’s address space and utilizes the
`bytecode program verifier to verify the integrity of the
`methods associated with each loaded class;
`a bytecode program verifier module 142 for verifying
`whether or not a specified program satisfies certain
`predefined integrity criteria; and
`a HTML loader 144 for loading HTML documents;
`as well as other modules.
`
`FIG. 2 illustrates the client computer that includes one or
`more processors 202, a communications interface 206, a
`user interface 204, a read-only memory 208 and a random
`access memory 210. The read-only memory 208 stores a
`portion of the browser 212 and support procedures
`(including an operating system 213 and network access
`procedures 214) that contain methods having no unresolved
`references and data that remains constant.
`
`
`
`3
`The browser, the HMTL documents, and the applets all
`reside in the computer’s RAM. On occasion, the amount of
`data that is loaded into RAM may exceed its capacity. As the
`client computer may have no secondary storage, it is advan-
`tageous to place portions of the browser and other basic
`support classes in a read-only memory. In this manner, RAM
`storage is preserved particularly for the imported applets.
`Preferably, the browser and other basic support classes (e.g.,
`I/O and utility classes) are preloaded in a read-only memory.
`The offline class loader partitions a Java application, such
`as the browser and the basic support classes, into at least two
`separate address spaces. A first address space resides in a
`read-only memory device and contains methods that do not
`require dynamic loading and data that remains constant. The
`second address space resides in a read/write memory device,
`such as random access memory, and contains methods that
`require dynamic loading and data that
`is varied during
`execution.
`
`A browser partitioned in this manner can be initially
`stored in the read-only memory of the client computer.
`When the system powers on, the second address space is
`preloaded into the RAM. This will leave a large amount of
`RAM storage for use by the browser to import HTML
`documents, applets, other information-context, and execut-
`able modules that are accessible through the communica-
`tions link.
`It should be noted that this disclosure is described with
`reference to the Java programming language. For this
`reason, this description will utilize the nomenclature of Java.
`The following Java nomenclature is used frequently
`throughout the description and will be described herein
`briefly. A class is a grouping of instance variables and
`methods that is used to describe the behavior of an object.
`An object is an instance of a class. An instance variable is
`the data of an object that is instantiated from a class. A static
`instance variable is one that will be the same for all instances
`of the class. A non-static instance variable varies for each
`instance of the class. Constant data refers to data that is not
`altered during program execution.
`A method is a program segment that performs a well-
`defined series of operations. In Java, a method is imple-
`mented by instructions represented as a stream of bytecodes.
`A bytecode is an 8-bit code that can be a portion of an
`instruction such as an 8-bit operand or opcode. An interface
`is an abstract class where the bytecodes that implement the
`method are defined at runtime. A Java application is an
`executable module consisting of bytecodes that can be
`executed using the Java interpreter or the Java just—in—time
`compiler. A more detailed description of the features of the
`Java programming language is described in Tim Ritchey,
`Programming with Java Beta 2.0, New Riders Publishing
`(1995).
`Referring to FIG. 1, there is shown a distributed computer
`system 100 having multiple client computers 102 and mul-
`tiple server computers 104. In an embodiment, each client
`computer 102 is connected to the servers 104 via the Internet
`106, although other types of communication connections
`could be used. Preferably, the server and client computers
`can be desktop computers, such as Sun workstations, IBM
`compatible computers and Macintosh computers, however,
`virtually any type of computer can be a server or client
`computer. Furthermore,
`the system is not
`limited to a
`distributed computer system. It may be practiced without the
`specific details and may be implemented in various com-
`puter systems and in various configurations, or makes or
`models of tightly-coupled processors or in various configu-
`rations of loosely-coupled microprocessor systems.
`
`10
`
`15
`
`,
`
`40
`
`45
`
`60
`
`65
`
`15
`
`used to produce a preloadable executable module. It should
`
`The random access memory 210 stores:
`a second portion of the browser 215 and support proce-
`dures 216, 217 that contains methods having unre—
`solved references and data that is altered during the
`application’s execution;
`a HTML document repository 220 containing one or more
`HTML documents 222 obtained by the browser at the
`request of the user through the user interface 204;
`a class file repository 224 containing one or more class
`files or applets 226; and
`one or more data files 228 that the client may utilize
`during its processing.
`FIG. 3 is an overview illustrating the sequence of steps
`
`15
`
`

`

`
`
`5
`the method and system described herein
`be noted that
`pertains to preloading the browser and other support proce-
`dures. However, the method and system described herein is
`not limited to these particular Java applications. Any Java
`application, or any other set of methods that are normally
`linked at run time could be preloaded using the method and
`system described herein.
`The source code 126 for each class that comprises the
`Java application is compiled by compiler 122 into a class file
`130. The class file contains class data structures representing
`the classes, each method’s bytecodes, constant data, as well
`as other information. Amore detailed description ofthe class
`file is provided below. Alternatively, the class files corre-
`sponding to the application can already reside in one or more
`class libraries 131. Once the class files are available, the
`entire set of class files 128 that constitute an application to
`be preloaded are transmitted to the offline class loader 132.
`The goal of the offline class loader 132 is to determine
`which methods and variables associated with each class can
`
`10
`
`15
`
`be stored in a read-only memory and which must be stored '
`in a random access memory device. Methods that invoke
`Java interfaces or utilize non-static instance variables need
`
`to reside in random access memory. This is because the
`bytecodes that implement interfaces are determined at runt-
`ime and non-static instance variables are altered for each /
`instantiation of the associated class. The offline class loader
`132 finds these methods and variables and flags them by
`inserting a special indicator that specifies that they are to be
`loaded in a random access memory device. The offline class
`loader also performs a number of optimizations in order to
`produce a more compact representation of the executable
`code. For example, the constant pool that is associated with
`each class is combined for all the classes residing in the
`application. In addition,
`the offline class loader performs
`additional processing to tailor the class files that were
`originally structured for dynamic loading for a preloaded
`class environment.
`The output of the offline class loader 302 can consist of
`two files: a constant pool file containing the constant data for
`the entire application; and an updated class file containing
`the class data structures and class members. The data in both
`of these files is formatted as data definitions, where each
`definition specifies a bytecode and an oifset indicating a
`memory location. The updated class file will include the
`memory storage indicators which will indicate in which type
`of memory storage device a particular set of bytecodes is to
`reside. However, the method and system described herein is
`not limited to producing these two files. Other file configu-
`ration can be used including, but not limited to, a single file
`containing all the related class data.
`The files are then transmitted to an assembler 134 which
`
`40
`
`45
`
`produces an object module having the required format for
`the linker to map the data into the appropriate address
`spaces. Preferably, there will be two address spaces, one for
`a random access memory device and a second for read-only
`memory device. The object module is then transmitted to the
`linker 136 which generates a memory layout for the classes
`in the application. Once the memory layout is determined,
`the linker 136 resolves all symbolic references and replaces
`them with direct addresses. The memory layout is parti-
`tioned into the two addresses spaces. The methods and data
`that were flagged for read-only memory are included in the
`first address space and the methods and data that were
`flagged as requiring storage in a random access memory are
`included in a second address space. The output from the
`linker 136 is a preloadable executable module 306 contain-
`ing the methods and data for these two address spaces.
`
`60
`
`65
`
`16
`
`and the appropriate class data structures for each class are
`
`5,815,718
`
`6
`The main function of the offline class loader as noted
`above is to determine the methods and data that are to be
`stored in a read-only memory and those that are to be stored
`in a random access memory. In addition, the constant pool
`for all the preloaded classes are preferably combined by the
`offline class loader,
`thereby minimizing the amount of
`read-only storage utilized. In order to combine the constant
`pools, certain optimizations are performed to reduce the
`amount of storage that
`is used. Specifically, duplicate
`expressions are eliminated and strings that are part of longer
`strings are replaced with pointers to the appropriate sub-
`string positions in the longer string.
`The universal constant pool, containing all the classes, is
`partitioned into two segments, the first segment spanning
`256 bytes and the second segment spanning 64k minus 256
`bytes. The first segment can contain at most 256 constants
`and the second segment contains the remaining constants.
`The constant pool is ordered such that the most frequently
`referenced constants are stored in the first segment of the
`pool and the least frequently referenced constants are stored
`in the second segment. Once the constant pool is combined,
`bytecodes that reference the constants may need to be
`adjusted. Constants in the first segment are referenced by an
`8-bit operand whereas constants in the second segment are
`referenced by two 8-bit operands (see FIG. 7 where operand
`702 is an 8-bit operand and operands 704 and 706 together
`form a 16-bit operand). The expansion from an 8-bit operand
`to a 16-bit operand requires adjusting those bytecodes that
`reference constants in the second segment of the universal
`constant pool, as well as adjustment of bytecode offset
`values (e.g.,
`in branch instructions)
`in the methods to
`account for the changed relative positions of the bytecodes
`in those methods. In addition, the alteration of the bytecodes
`requires updating the offsets stored in the exception table to
`reflect the changed bytecode start and end positions within
`the methods to which various exception handlers are
`assigned.
`Further, the offline class loader performs two other trans-
`formations in order to tailor the class structure to one suited
`
`for preloading classes. A static class initializer is created,
`which performs class initialization for the classes that are
`preloaded. Also bytecodes using a non-quick instruction
`format that symbolically reference methods are recoded in a
`quick instruction format
`that references the methods
`directly.
`FIG. 8 illustrates in further detail the steps used by the
`offline class loader 132. Initially the offline class loader
`receives a class file for each class that
`is part of the
`application whose classes are to be preloaded. FIG. 4
`illustrates a format for the class file. The class file contains
`
`one or more header records 402, a constant pool 404, one or
`more methods 406, and an exception table 408. The header
`records 402 can indicate the size of the constant pool, the
`number of methods, and the size of the exception table. The
`constant pool 404 includes data that remains unaltered
`during the execution of the application. Examples of such
`data can include string constants, static final integers, ref-
`erences to methods, references to classes, and references to
`interfaces. The method data 406 consists of a stream of
`bytecodes that implement each method. Each entry in the
`exception table gives a start and end offset
`into the
`bytecodes, an exception type, and the offset of a handler for
`the exception. The entry indicates that when an exception of
`the indicated type occurs within the code indicated by the
`starting and ending offsets, a handler for the exception will
`be found at the given handler offset.
`Each class file is read by the offline class loader (step 802)
`
`16
`
`

`

`5,815,718
`
`
`
`7
`built (step 804), that is stored in the memory of the computer
`being used to preprocess the application. FIG. 6 illustrates
`the class data structures 600. For each class there is a class
`
`block 602, one or more method blocks 604, bytecodes for
`each method 608, one or more field blocks 614, separate data
`areas for the fields 618, a constant pool 624, a map table 626
`and an exception table 628.
`The class block is a fixed-size data structure that can
`include the following data:
`the class name 630;
`a pointer 632 to the class block of the current class”
`immediate superclass;
`an array of one or more pointers 634, each pointer
`referencing a method block;
`an array of one or more pointers 636, each pointer
`referencing a field block;
`a pointer 638 to the class’ constant pool; and
`a pointer 640 to the class” exception table.
`A method block 604 is a fixed-sized data structure that
`contains a predetermined number of methods. One or more
`method blocks are allocated to contain all the methods of a
`class. A method block 604 contains the method’s name 612
`and a pointer 610 to the corresponding bytecodes 608.
`A field block 614 is a fixed-size data structure that
`contains instance variables or fields. There is a diflerent field
`block format for each of the two different types of instance
`variables provided in Java. The first format 616 is used for
`integer or floating point instance variables. This format 616
`contains the name of the instance variable, the type (e.g.
`integer or floating point), and its value. The second format
`620 is used for double or long type instance variables. This
`format 620 contains the name of the instance variable, the
`type (e.g., double or long) and a pointer to location of the
`value of the instance variable 618.
`
`FIG. 9 illustrates the steps used to build the class data
`structures. The information in the header record is used to
`
`10
`
`15
`
`'
`
`/
`
`allocate space for each of the class data structures (step
`1002). Once the class data structures are allocated, pointers
`to the location of each of these structures is included in the
`
`40
`
`class block (step 1004).
`Next, the offline class loader reads in the constant pool.
`Prior to discussing these steps, the content of the constant
`pool will be described first. FIG. 5 illustrates the structure of
`the constant pool that is stored in each class file. A first entry
`contains the name of the class and the name of the superclass
`502. These names are stored as string constants and the first
`entry contains pointers to the locations of those strings in the
`constant pool. The next entry pertains to the fields or
`instance variables. A header 504 is used to denote the
`number of fields in the constant pool. The various fields 506
`follow the header.
`
`Likewise, the string constants are preceded by a header
`508 that indicates the number of string constants in the
`constant pool. The various string constants 510 follow.
`String constants are used to denote method names, class
`names, and interface names. Next, the method references are
`stored in the constant pool preceded by a header indicating
`the number of methods 512. The constant pool contains for
`each method a method pointer 511 that contains a pointer to
`the method’s name 514 and the method’s class name 516.
`
`These names