International Business Machines Corporation

Marc Noel Blais

William Jon Schmidt

Daniel Rodman Hicks

James Albert Kryka

An apparatus and method provide a cache for analyzed program information when no class file can be identified. When loading a class, if there is an identifiable class file for the class, the class file is checked to determine if analyzed program information is attached. If so, the analyzed program information can be directly used without the overhead of analyzing the program information again. If there is no identifiable class file for the class, a cache is checked to see if there is an entry in the cache corresponding to the class. If there is no entry in the cache corresponding to the class, the program information is analyzed and saved in a cache entry for future use. If there is an entry in the cache corresponding to the class, the analyzed program information is retrieved and used, thereby saving the time required to repeatedly analyze the program information.

Apparatus and method for caching analyzed program information

An object oriented mechanism and method allow allocating Java objects on a method's invocation stack in a partial compilation environment under certain conditions. Only the classes that are visible are taken into account when performing escape analysis in accordance with the preferred embodiments. In a first aspect of the invention, conservative assumptions are made to assure that objects are only allocated on an invocation stack when this can be proven safe by examining only those classes in the compilation unit. In a second aspect of the invention, the concept of visible classes is extended to include other classes that may be found from a user-defined classpath that matches the anticipated run-time classpath used to find classes during program execution. When stack allocation decisions for a method depends on such classes that are outside the compilation unit, two versions of run time code for that method are created. One version allocates all objects from the heap, whereas the other allocates some or all objects on the invocation stack. For each class outside the compilation unit that was examined when making stack allocation decisions for a method, information about the requisite class is stored with the method. At run time, the class loader verifies that the run time version of each requisite class matches all stored information about that class. If all information matches for all requisite classes, the version of the method using stack allocation is safe to use at run time. Otherwise, the method using heap allocation must be used.

Object oriented apparatus and method for allocating objects on an invocation stack in a partial compilation environment

According to the preferred embodiments, an object oriented mechanism and method allow creating system level Java code that is protected, and therefore cannot be accessed or extended by unauthorized users or programs. Several new tests are performed during loading, linking, and initialization of a class that assure that the class is as the operating system expects. In addition, one or more runtime tests may be performed to prevent programs from getting into the Java system level code via a runtime 'back door.' By providing additional tests when classes are loaded and when certain types of methods and functions are invoked at runtime, the Java system level code is protected from unauthorized access and use.

Method and apparatus for creating and enforcing protected system level Java code

An object oriented mechanism and method allow allocating a greater number of objects on a method's invocation stack. Each instruction that creates an object (i.e., allocation instruction) is first analyzed to determine whether it is one of the following three types: no escape, global escape, and arg escape. If an allocation instruction is global escape, the object must be allocated from the heap. If an allocation instruction is no escape, it can be allocated on the method's invocation stack frame. If an allocation instruction is arg escape, further analysis is required to determine whether the object can be allocated on an invoking method's stack or must be allocated from the heap. If the method that contains an arg escape allocation instruction can be inlined into a method from which the lifetime of the object does not escape, the object can be allocated on the invoking method's stack. This inlining can be done for several layers up, if needed and possible. This allows for nested objects to be potentially allocated on a method's stack, instead of forcing each of these objects to be allocated from the heap.

Growing community of inventors

Rochester, MN, United States of America

Marc Noel Blais