US20140075422A1

US20140075422A1 - Method for dynamically transforming the bytecode of java virtual machine bootstrap classes

Info

Publication number: US20140075422A1
Application number: US13/885,915
Authority: US
Inventors: Michael Rasmussen; Allan Raundahl Gregersen; Bo Norregaard Jorgensen
Original assignee: Syddansk Universitet
Current assignee: Perforce Software AS
Priority date: 2010-11-16
Filing date: 2011-11-02
Publication date: 2014-03-13
Also published as: US9141415B2; WO2012065845A1

Abstract

Under the present invention, a method for dynamically transforming the bytecode of Java Virtual Machine (JVM) bootstrap classes during program startup is provided. A JVM agent is used to intercept the execution flow before the execution of the special program startup-method of a JVM compliant computer program. The said JVM Agent executes code to transform the bytecode of the already loaded JVM bootstrap classes, storing the new set of modified bootstrap classes onto data storage. Subsequently, the JVM Agent intercepts all class loading events transforming the bytecode of classes declaring a special program statrup-method. In those classes the bytecode within the method body of the special class-initialize method, as defined in the present JVM class file format as “<clinit>”, is removed to avoid any side-effects in the program. The special program startup-method in the said classes is transformed to insert bytecode at the beginning of the method to invoke a special callback method, as declared within the said JVM Agent, passing as parameters to the callback method the main arguments as passed to the JVM upon program startup. Subsequently, when the said callback method intercepts the execution flow it starts a second JVM instance passing to it the obtained input parameters, the main method arguments as well as a JVM input argument to use the stored set of modified bootstrap classes.

Description

FIELD OF THE INVENTION

The present invention relates to the ability to perform bytecode transformations to enable user-defined customizations of the behavior of computer programs running on top of an unmodified JVM. More particularly, the present invention enables transparent bytecode transformations of the special JVM bootstrap classes in order to obtain full bytecode coverage of user-defined customizations for existing classes. With the present invention, computer programs requiring bytecode transformations of the foresaid bootstrap classes, beyond the capabilities of the current Java HotSwap mechanism, no longer have to use an off-line transformation tool that performs the required bytecode transformations statically to the bootstrap classes before the computer program can be started on the JVM with the modified bootstrap classes. Rather, the present invention enables transparent on-line bytecode transformations and automatic program execution with the set of hereby dynamically modified bootstrap classes.

BACKGROUND OF THE INVENTION

Altering the semantics of a JVM compliant computer program via bytecode transformation is a well-known practice. Bytecode transformation has been used for many purposes, especially to enhance programs with new capabilities and or add monitoring or profiling. A widespread objective when applying bytecode transformation is full bytecode coverage of the bytecode being executed in the JVM, meaning that every class loaded into or as part of the JVM should be intercepted by the bytecode transformer to permit bytecode modifications. In contrary, incomplete bytecode coverage would cause a lack of bytecode enhancement for parts of the program that depends on modifications of parts which cannot be changed by current available techniques. Currently many available techniques for bytecode transformation are limited in their support for full bytecode coverage. Firstly, certain core classes (the special bootstrap classes) of the JDK are completely excluded from instrumentation because they are loaded before bytecode transformation can take place. Consequently, the bytecode executed within these classes corresponds to the unmodified versions of the classes. Secondly, because of the first cause, transformation of boot-classes has to be performed statically meaning the whole method has to be transformed prior to execution.
The JDK 1.5 has introduced a mechanism, Java language instrumentation agents (package java.lang.instrument), to transform classes as they are being loaded. Even though instrumentation agents are loaded and executed before the class containing the main(String[ ]) method, these agents are loaded only after the JVM has completed bootstrapping. At this stage of the execution, already several hundred classes have been loaded but not been processed by any instrumentation agent. The JDK offers a mechanism to redefine these pre-loaded classes, which however imposes several strong limitations on class redefinition, as summarized in the JDK 1.6 API documentation: The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance.' These limitations are far too restrictive for many instrumentation-processes, such as e.g. for calling context reification which requires the introduction of additional method arguments and therefore changes method signatures. The present invention does not suffer from these strong limitations as it enables full modification of already loaded bootstrap classes.
In [1] Binder et al. discloses the method FERRARI as a general-purpose bytecode instrumentation framework. In FERRARI it's possible to instrument all classes including the special JVM bootstrap classes. However, the method requires the bytecode modifications of the JVM bootstrap classes to be done by a special static transformation tool called FIRST. Hence, FERRARI requires users to accept a two-step process in which the application is first prepared to execute, and then the real execution can be carried out. Not only does this alter the standard usage pattern of executing Java programs, but more importantly it requires the user to remember to execute the preparation tool.

SUMMERY OF THE INVENTION

An embodiment of the present invention provides a method for transparently performing user-defined customizations of the bootstrap classes of an actively running Java Virtual Machine (JVM) on a desktop, server, mainframe, cloud computing or embedded computing device.
Specifically, under the present invention, user-defined customization of bootstrap classes no more requires use of an off-line bytecode transformation tool that change the bytecode of bootstrap classes before startup of the JVM, instead bytecode transformation of bootstrap classes is transparently performed on-line as part of startup of a JVM compliant computer program using a special instance of a JVM Agent.
The invention operates by having the said JVM Agent executing code to transform the bytecode of the already loaded JVM bootstrap classes accordantly to the required user-defined customizations and storing the hereby-resulting set of modified bootstrap classes onto data storage.
Next, the invention has the JVM Agent intercepting all class-loading events and transforming the bytecode of those classes declaring the special program startup-method with the unique method signature“public static void main(String[ ])”, by inserting bytecode at the beginning of the special startup-method to call a callback method in the said JVM Agent. Further, in those classes declaring the special program startup-method, the inventions has the said JVM Agent to remove the bytecode within the body of the special class-initialize method, as defined in the present JVM class file format as “<clinit>”, to avoid any side-effects in the program.
Subsequently, when the JVM hands over control to a compliant computer program's special program startup-method, the bytecode inserted therein calls the callback method on the said JVM Agent, passing as parameters the same set of arguments as passed to the JVM upon initial program startup. Then, when the call-back method has control it spawns a new operating system process executing a second JVM instance, passing to it the obtained input parameters, the main method arguments as well as a JVM input argument to use the stored set of modified bootstrap classes. On return from spawning the operating system process of the second JVM instance, the callback method executes code for waiting for the process actively running the second JVM instance to terminate, before the callback method terminates the first JVM instance.
In a variant of this embodiment, the tasks of the said JVM Agent are equally performed as part of a modified JVM.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. These drawings depict only one or more typical embodiments of the invention and are not therefore to be considered to be limiting of its scope. With respect to the following drawings, like reference numbers denotes the same element throughout the set of drawings.

FIG. 1 is a block diagram of a generic computing device, which could be a desktop, workstation, server, mainframe computer, embedded computing device, etc., wherein the present invention may be practiced.

FIG. 2 is a flowchart showing the steps taken to dynamically instrument the bytecode of bootstrap classes.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram of a computing device, such as a workstation, wherein the present invention may be practiced. The environment of FIG. 1 comprises a single representative computing device 100, such as a personal computer, workstation, enterprise mainframe computer, server, laptop, hand-held computer, information appliance, etc., including related peripheral devices. The computing device 110 includes a microprocessor 102 or equivalent processing capability and a bus 104 to connect and enable communication between the microprocessor 102 and the components of the computing device 100 in accordance with known techniques. Note that in some computing devices there may be multiple processors incorporated therein.
The microprocessor 102 communicates with storage 106 via the bus 104. Memory 108, such as Random Access Memory (RAM), Read Only Memory (ROM), flash memory, etc. is directly accessible while secondary storage device 110, such as a hard disk, and removable storage device 112, such as a floppy diskette drive, CD ROM drive, tape storage, etc. is accessible with additional interface hardware and software as is known and customary in the art. The removable storage device 112 will have associated therewith an appropriate type of removable media 114, such as a diskette, CD, tape reel or cartridge, solid state storage, etc. that will hold computer useable data and is a form of computer useable medium. Note that a computing device 100 may have multiple memories (e.g., RAM and ROM), secondary storage devices, and removable storage devices (e.g., floppy drive and CD ROM drive).
The computing device 100 typically includes a user interface adapter 116 that connects the microprocessor 102 via the bus 104 to one or more interface devices, such as a keyboard 118, a mouse or other pointing device 120, a display 122 (such as a CRT monitor, LCD screen, etc.), a printer 124, or any other user interface device, such as a touch sensitive screen, digitized entry pad, etc. Note that the computing device 100 may use multiple user interface adapters in order to make the necessary connections with the user interface devices.
The computing device 100 may also communicate with other computing devices, computers, workstations, etc. or networks thereof through a communications adapter 126, such as a telephone, cable, or wireless modem, ISDN Adapter, DSL adapter, Local Area Network (LAN) adapter, or other communications channel. This gives the computing device direct access to networks 128 (LANs, Wide Area Networks (WANs), the Internet, etc.), telephone lines 130 that may be used to access other networks or computers, wireless networks 132, such cellular telephone networks, and other communication mechanisms. Note that the computing device 100 may use multiple communication adapters for making the necessary communication connections (e.g., a telephone modem card and a Cellular Digital Packet Data (CDPD). The computing device 100 may be associated with other computing devices in a LAN or WAN, or the computing device can be a client or server in a client/server arrangement with another computer, etc. All these configurations, as well as the appropriate communications hardware and software, are known in the art.
The computing device 100 provides the facility for running software, such as Operating System software 134, Middleware software 136, and Application software 138. Note that such software executes tasks and may communicate with various software components on this and other computing devices.
As will be understood by one of ordinary skill in the art, computer programs such as that described herein (including Operating System software 134, Middleware software 136, and/or Application software 138) are typically distributed as part of a computer program product that has a computer useable media or medium containing or storing the program code. Therefore, “media”, “medium”, “computer useable medium”, or “computer useable media”, as used herein, may include a computer memory (RAM and/or ROM), a diskette, a tape, a compact disc, an integrated circuit, a programmable logic array (PLA), a remote transmission over a communications circuit, a remote transmission over a wireless network such as a cellular network, or any other medium useable by computers with or without proper adapter interfaces. Note that examples of a computer useable medium include but are not limited to palpable physical media, such as a CD Rom, diskette, hard drive and the like, as well as other non-palpable physical media, such as a carrier signal, whether over wires or wireless, when the program is distributed electronically. Note also that “servlets” or “applets” according to JAVA technology available from Sun Microsystems out of Mountain View, Calif., would be considered computer program products.
Although the enabling instructions might be “written on” on a diskette or tape, “stored in” an integrated circuit or PLA, “carried over” a communications circuit or wireless network, it will be appreciated, that for purposes of the present invention described herein, the computer useable medium will be referred to as “bearing” the instructions, or the instructions (or software) will be referred to as being “on” the medium. Thus, software or instructions “embodied on” a medium is intended to encompass the above and all equivalent ways in which the instructions or software can be associated with a computer useable medium.
For simplicity, the term “computer program product” is used to refer to a computer useable medium, as defined above, which bears or has embodied thereon any form of software or instructions to enable a computer system (or multiple cooperating systems) to operate according to the above-identified invention.
It will be likewise appreciated that the computer hardware upon which the invention is effected contains one or more processors, operating together, substantially independently, or distributed over a network, and further includes memory for storing the instructions and calculations necessary to perform the invention.
Those skilled in the art will recognize that a method according to the present invention may be created in a variety of different ways known in the art. For example, a general purpose computing device as described in FIG. 1 may be configured with appropriate software so that the computing device functions as described hereafter. Furthermore, discrete electronic components may be used to create a system or computer program product that implements all or part of the functional. Finally, note that combinations of multiple computing devices running appropriate software or discrete electrical components can be used in like fashion. Essentially, the hardware is configured (whether by software, custom designed, etc.) to perform the functional elements making up the present invention.
Referring now to FIG. 2, a flowchart showing the steps taken to transparently transform the bytecode of the special bootstrap classes, automatically executing a new program instance wherein the transformed set of bootstrap classes are prepended to the boot class path of the JVM. Initially, at 202 the flow of events is triggered by a request to start a computer program instance in the JVM. In some embodiments of the present invention an additional input argument to setup a JVM Agent that intercepts the program execution before the execution point of the computer program startup-method is passed to the JVM 204. In 206 the virtual machine transfers control to the JVM Agent as specified as the additional input argument. The JVM Agent obtain a reference to the set of already loaded classes, namely the bootstrap classes in 208, transforming the bytecode of those bootstrap classes, saving the modified set of bootstrap classes onto a data storage in step 210. In step 212 the code in the JVM Agent sets up a class file transformer that intercepts the class loading process for all further class loading events in the JVM. On every class-loading event happening in the computer program the class file transformer intercepts the class loading in 214, transforming the bytecode of those specific classes wherein the special application startup-method, main(String[ ]) method, is declared. In those specific main classes the bytecode, if such bytecode exists, contained within the method body of the special class initialize method (<clinit>) is removed. Moreover, the class file transformer inserts bytecode at the beginning of the special program startup-method to invoke a callback method of a class declared within the Java agent passing the main arguments to the callback method as method parameters. Once the callback method is first executed in 216 the callback method collects the remaining input arguments of the computer program. Afterwards, in 218 a new computer program instance of the said computer program is executed, on a new JVM instance within a new operating system process, with the set of obtained input arguments, the main method arguments, in addition to an argument that defines a new prepending boot class path at the location where the modified set of bootstrap classes was stored. In some embodiments, the JVM Agent as given to the first computer program instance is passed on to the new JVM instance, and once the JVM Agent intercepts the execution flow of the new computer program instance, it determines if the special instrumentation of described by steps 208-218 was already preformed by the previously executed computer program instance, and if so, it will skip the steps of 208-218. In 220 the callback method blocks further execution of the first computer program instance by waiting for the process running the second JVM instance to terminate. Once the second JVM instance terminates the callback method is wakened just to terminate execution of the first computer program.
[1] W. Binder, J. Hulaas, and P. Moret. Advanced Java Bytecode Instrumentation. 5th International Symposium on Principles and Practice of Programming in Java (PPPJ-2007), Lisboa, Portugal, September 2007. ACM Press, ISBN 978-1-59593-672-1, pp. 135-144.

Claims

1. A method for transparently re-launching a Java Virtual Machine compliant computer program from within an actively running Java Virtual Machine instance initially booted with a set of standard bootstrap classes, into a new Java Virtual Machine instance booted with a set of dynamically generated bootstrap classes, comprising:

transforming the byte-code of already loaded bootstrap classes in the actively running Java Virtual Machine instance accordantly to a required set of user-defined customizations, storing the hereby-resulting set of modified bootstrap classes onto an alternative boot class path location at a computer data storage medium;

intercepting the loading event of byte-code on every non-bootstrap class loaded into the said actively running Java Virtual Machine instance and once class loading is initiated on a particular non-bootstrap class, testing if the class declares a Java Virtual Machine's special program startup-method, and if so, in successive phases,

transforming the byte-code of the special class-initialize method as defined in the Java Virtual Machine class file format as “<clinit>”, into a modified special class-initialize method with an empty method body,

inserting byte-code at the beginning of the said special program startup-method to intercept the argument passed to the said special program startup-method when called by the Java Virtual Machine upon start of program execution,

inserting byte-code at the beginning of the said special program startup-method to redirect the execution flow and the arguments passed to the said special program startup-method upon start of program execution to a special callback method

that intercepts the program execution flow on handover of control from the actively running Java Virtual Machine instance to the said special program startup-method, in the callback method comprising:

starting a new Java Virtual Machine instance,

passing to the new Java Virtual Machine instance the same set of arguments as passed to the said actively running Java Virtual Machine instance upon initial program startup, as well as a Java Virtual Machine specific input argument to use the stored set of modified bootstrap classes,

blocking further execution of the said callback method upon returning from starting the second Java Virtual Machine instance and once the said second Java Virtual Machine instance terminates its execution, the said callback method awakes

2. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes changes the interface of some or all of the bootstrap classes.

3. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes add, modify or remove fields in some or all of the bootstrap classes.

4. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes add, modify or remove methods in the bootstrap classes.

5. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes add, modify or remove constructors in the bootstrap classes.

6. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes changes the super class of some or all of the bootstrap classes.

7. The method of claim 1 wherein the modifications to the bytecode of the bootstrap classes changes the list of implemented interfaces for some or all of the bootstrap classes.

8. The method of claim 1, wherein byte-code transformation is performed by the Java Virtual Machine.

9. The method of claim 1, wherein the callback method is provided by the Java Virtual Machine.

10. The method of claim 8, wherein the Java Virtual Machine performs no byte-code transformation of claim 1 when it is started with an alternative boot class path.

11. The method of claim 1, wherein byte-code transformation is performed by a separate computer program called by the Java Virtual Machine, a so-called Java Virtual Machine Agent.

12. The method of claim 1 wherein the callback method is provided by a separate computer program called by the Java Virtual Machine, a so-called Java Virtual Machine

13. The method of claim 11, wherein the Java Virtual Machine Agent is not provided as argument to the new Java Virtual Machine instance started by the callback method of claim 1.

14. The method of claim 1, wherein the Java Virtual Machine is compliant to the Java Virtual Machine specification.

15. (canceled)