US20090150863A1 - Type checking for object-oriented programming languages - Google Patents

Type checking for object-oriented programming languages Download PDF

Info

Publication number
US20090150863A1
US20090150863A1 US10/583,648 US58364805A US2009150863A1 US 20090150863 A1 US20090150863 A1 US 20090150863A1 US 58364805 A US58364805 A US 58364805A US 2009150863 A1 US2009150863 A1 US 2009150863A1
Authority
US
United States
Prior art keywords
class
type checking
hotspot
response
target class
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/583,648
Other versions
US9009688B2 (en
Inventor
Peng Guo
Xiaohua Shi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Assigned to INTEL CORPORATION reassignment INTEL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GUO, PENG, SHI, XIAOHUA
Publication of US20090150863A1 publication Critical patent/US20090150863A1/en
Application granted granted Critical
Publication of US9009688B2 publication Critical patent/US9009688B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/43Checking; Contextual analysis
    • G06F8/436Semantic checking
    • G06F8/437Type checking

Definitions

  • Object-oriented programming languages may support inheritance, which may use an existing type to derive a new type. Derived types may inherit data and operations of super-type of the derived types; and they may overwrite existing operations or add new ones.
  • Complex object-oriented programs may contain complex inheriting hierarchies. These hierarchies may often require that the program explicitly convert an object reference from one type to another type. This type of conversion may need run-time type checking that may be used to check whether the object is cast into an invalid target type.
  • object-oriented programming languages besides a memory to store fields of an object, each object may have an object header to provide basic services of object-oriented programming, such as class hierarchies with virtual methods, and other metadata that may be tapped into for different kinds of uses.
  • FIG. 1 illustrates an embodiment of a system that may implement type checking.
  • FIG. 2 illustrates an embodiment of a data structure that may be used in the present invention.
  • FIG. 3 illustrates an embodiment of a checkcast process that may be used in type checking for an object-oriented programming language.
  • FIG. 4 illustrates an embodiment of an instanceof process that may be used in type checking for an object-oriented programming language.
  • FIG. 5 is a block diagram illustrating an embodiment of a system that may dynamically generate type checking code in a Java run-time environment.
  • FIG. 6 is a schematic diagram of a type checking related process according to an embodiment of the present invention.
  • references in the specification to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • Embodiments of the invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors.
  • a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device).
  • a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.
  • FIG. 1 illustrates an example system that may implement the methods of the present invention.
  • system 100 may comprise a processor 110 .
  • Processor 110 may coupled with a memory 120 via a bus 115 .
  • Processor 110 may be any type of processor adapted to execute instructions from memory 120 .
  • processor 110 may be a microprocessor, a digital signal processor, a microcontroller, or the like.
  • processor 110 and memory 120 may be included on an integrated circuit board, and bus 115 may be implemented using traces on the circuit board. In another embodiment, processor 110 and memory 120 may be included within the same integrated circuit, and bus 115 may be implemented using interconnect within the integrated circuit.
  • processor 110 may execute a first compiler 130 .
  • the first compiler 130 may comprise any type of compiler adapted to output instructions for type checking.
  • the first compiler 130 may comprise a Java compiler that may output Java byte codes for runtime checking.
  • processor 110 may execute a Java Virtual Machine (JVM) 140 .
  • JVM 140 may be implemented with a Just-In-Time (JIT) compiler.
  • JVM 140 may be coupled with the first compiler 130 to translate the Java byte codes outputted from the first compiler 130 to architecture specific native codes.
  • the first compiler 130 and/or JVM 140 may be implemented with software that may be stored in memory 120 .
  • processor 110 may perform operations according to the instructions from JVM 140 , for example, a process as shown in FIG. 3 or 4 .
  • FIG. 3 illustrates a flowchart showing an embodiment of a method that may be used in type checking for an object-oriented programming language.
  • the following description may be focused on Java that is one of the object-oriented programming languages; however, other embodiments may be used for other dynamically compiled object-oriented programming languages such as, for example, C#, Python, LISP, etc.
  • Java may have one or more, e.g., five, conversion contexts in which conversion expression may occur.
  • an example conversion from type S to type T may allow an expression of Type S to be treated at compiling time as if it had type T instead.
  • a corresponding action may be made at run time to check the validity of the conversion.
  • Java Virtual Machine 140 may use one or more byte codes or instructions, e.g., checkcast and instanceof, for performing type checking on an object.
  • processor 110 may obtain an object header.
  • processor 110 may get the object header from an object handle of an object 200 as shown in FIG. 2 .
  • object header 205 may comprise one or more bits that may represent the class of the object.
  • Numerical reference 220 may represent a data structure.
  • data structure 220 may be implemented as table, array, list or the like.
  • data structure 220 may comprise a target class table.
  • data structure 220 may comprise one or more entries that each may comprise a target class handle associated with a hotspot.
  • the data structure 220 may be dedicated to one object, or shared by one or more objects inside JVM 140 .
  • numerical reference 230 may refer to a second object.
  • the second object 230 may comprise a second object header 235 that may be obtained from a second object handle 2 ; however, other embodiments may comprise a different number of objects.
  • processor 110 may use dynamic profiling to find out one or more hotspots, e.g., during program running.
  • a hotspot may refer to a hot check point that may be a location in a program at which the type checking operation from objects to a given target class occurs one or more times, e.g., a lot of times, during program running.
  • the processor 110 may deduce a target class from a type checking hotspot.
  • target class handle 222 may contain class identification of a first target class; target class handle 224 may contain class identification of a second target class; and target class handle 226 may contain class identification of the nth target class; however, other embodiments may identify target classes with different information.
  • the method of FIG. 3 may be used for type checking associated with a hotspot.
  • one or more type checking hotspots with the same target class may share the same bit indicator of an object header and thus the same target class entry.
  • the first object header 205 may allocate one or more bits 210 that each may correspond to an entry in data structure 220 .
  • the second object header 235 may allocate each of one or more bits 240 to a corresponding entry in data structure 220 .
  • bit 212 may be allocated to the first entry 222 ;
  • bit 214 may be assigned to the second entry 224 ;
  • bit 242 may be assigned to the nth entry 226 ; however, other embodiments may allocate a bit for an entry in a different order.
  • JVM 140 may assert the one or more bits 210 in the first object header 205 and/or one or more bits 240 in the second object header 235 as indicators that may each indicate whether a type checking associated with a corresponding entry is successful.
  • the one or more bit indicators 210 and/or 240 may have a first logic value (for example, “0”) in their initial states.
  • Processor 110 may assert a bit indicator 210 and/or 240 corresponding to an entry to a second logic value (for example, “1”), in response to determining that a type checking associated with the entry is successful.
  • processor 110 may check whether a bit indicator 210 in object header 205 of the object is asserted. For example, processor 110 may determine whether the bit indicator 210 that is allocated to a target class of the hotspot is asserted to a second logic value (for example, “1”). In response to the bit indicator 210 being asserted, processor 110 may determine that the type checking between the object class and the target class associated with the hotspot is successful and may terminate the type checking at the hotspot.
  • a second logic value for example, “1”.
  • JVM 140 may call a function that may be stored in memory 120 to perform a type checking for the object class, in response to determining that the bit indicator 210 is deasserted.
  • processor 110 may call the function, in response to determining that the bit indicator 210 has a first logic value or the bit indicator 210 is in its initial state.
  • the function may comprise a special checkcast helper, for example, with reference to blocks 308 , 310 , 312 , 314 , 316 and 318 .
  • processor 110 may determine whether the object class of the current object and the target class match a predetermined criterion/condition.
  • processor 110 may traverse the super classes of the class of the current object to see whether one of the super classes could be the same as the target class. For example, the type checking for the class of the current object is successful, in response to the processor 110 determining that one of the super classes is the same as the target class.
  • processor 110 may traverse a class hierarchy associated with the class of the current object to determine whether the target class is represented in the class hierarchy based on one or more predetermined criteria or conditions. For example, the processor 110 may determine that the type checking between the class of the current object and the target class is successful, in response to determining that the target class is represented in the class hierarchy.
  • the class hierarchy may be implemented as an array of class references or the like that may be used to perform type checking in Java computing environments.
  • the class hierarchy may represent all the parent classes of Java classes in a hierarchical relationship.
  • processor 110 may assert a bit indicator 210 in the object header of the current object to indicate that the type checking between the object class and the target class is successful.
  • processor 110 may assert the bit indicator 210 to a second logic value.
  • the bit indicator 210 may correspond to an entry in data structure 220 that represents a target class, for example, class handle, associated with a hotspot.
  • processor 110 may return the result indicating that the type checking between the object class and the target class is successful or the object class and the target class matches a predetermined criterion/condition. For example, processor 110 may return “True”. In another embodiment, processor 110 may return a “True” result before asserting the bit indicator 210 .
  • processor 110 may return a corresponding result, for example, “False” (block 314 ).
  • processor 110 may determine whether the object has passed the type checking based upon the result returned in blocks 312 or 314 . For example, in response to determining that the object has not passed the type checking based on a result “False” or a failure result, processor 110 may throw an exception (block 318 ). Conversely, in response to a pass result, e.g., “True”, the type checking flow of FIG. 3 is ended. In one embodiment, processor 110 may continue other operations of the system 100 .
  • FIG. 4 is a flowchart illustrating a method according to another embodiment of the present invention.
  • the process of FIG. 4 is similar to that of FIG. 3 except blocks 406 , 418 and 420 .
  • processor 110 may call a function that may be stored in memory 120 , in response to determining that a bit indicator 210 associated with a target class of a type checking hotspot has not been asserted.
  • processor 110 may call a special instanceof helper.
  • processor 110 may push a first code, e.g., a True code, on an operand stack of memory 120 in response to determining that the object has passed the type checking.
  • a second code e.g., a False code
  • the hot or hottest check points (using, e.g., either checkcast or instanceof bytecode), that consume most runtime on type checking may occur at several points (thus for several target classes). And, type checkings at one or more or most of the hot or hottest check points may be successful, e.g., in most cases.
  • the method as shown in FIG. 3 or 4 may be used for every such check point.
  • the JVM 140 may use dynamic profiling to find out hot check points that are either checkcast or instanceof bytecode, during the processor executing the Java program, in which the type checking are made using conventional methods.
  • FIGS. 3 and 4 are illustrated as a sequence of operations, the illustrated operations may be performed in a different order in other embodiments.
  • FIG. 5 is a block diagram illustrating an embodiment of a system 500 that may execute Java program in, e.g., system 100 .
  • the system 500 may be a Java runtime system.
  • the system 500 may contain a dynamic compiler 534 that may translate the Java program's bytecode into instructions of the processor 110 that may be executed directly on processor 110 .
  • the dynamic compiler 534 may dynamically generate type checking code.
  • system 500 may comprise a first compiler 510 that may compile Java source code 502 to Java byte code 504 .
  • the first compiler 510 may be itself a computer program.
  • a loader 532 may load the byte codes 504 into JVM 530 .
  • a dynamic compiler 534 in JVM 530 may turn the byte code 504 loaded via loader 532 into native code 508 associated with the program.
  • the dynamic compiler 534 may comprise a “just-in-time” (JIT) compiler or the like.
  • JVM 530 may comprise an interpreter to interpret the byte codes 504 .
  • JVM 530 may comprise a profiler 536 that may perform dynamic profiling during the program running to detect one or more hot check points, i.e., hotspots, that may occur at several points (thus for several type classes) in a program. Profiler 536 may return the detected hotspots 506 to dynamic compiler 534 .
  • hot check points i.e., hotspots
  • FIG. 6 is a schematic diagram of a type checking related process 600 that may be generated by JVM 530 .
  • block 610 may refer to the native instructions of processor 110 translated from Java bytecodes 504 .
  • dynamic compiler 534 may use normal methods to generate type checking code at the first time compilation. For example, dynamic compiler 534 may generate type checking code to call normal checkcast helpers 612 and 616 and a normal instanceof helper 614 for the type checking; however, other embodiments may use different functions for type checking in a different order.
  • the normal type checking helper may get a class of an object and traverse a class hierarchy to check whether the object class and target class meets a criteria, which may be time consuming.
  • profiler 536 may perform dynamic profiling to detect type checking hotspots, which may trigger a second time compilation for these hotspots in dynamic compiler 534 . Referring to FIG. 6 , profiler 536 may determine a hotspot 622 of the checkcast helper 612 and a hotspot 624 of the instanceof helper 614 .
  • dynamic compiler 534 may deduce a target class for a hotspot of checkcast or instanceof helper. For example, dynamic compiler 534 may deduce a target class for hotspots 622 and 624 that relates to a normal checkcast helper and a normal instanceof helper, respectively. Dynamic compiler 534 may allocate an entry in data structure 220 to save the target class handle of the deduced target class and a corresponding bit indicator in an object for the entry. Referring to FIG. 2 , in one embodiment, one bit indicator 210 may comprise a bit in object header 205 of an object 200 (the bit may be cleared by default).
  • Dynamic compiler 534 may regenerate type checking code (for example, block 630 ) to check the bit indicator 210 and call a special helper for the hotspot.
  • type checking code for hotspot 622
  • dynamic compiler 534 may regenerate type checking code to check whether a bit indicator associated with hotspot 622 is asserted and call a special checkcast helper 632 .
  • type checking code for hotspot 624
  • dynamic compiler 534 may regenerate type checking code to check whether a bit indicator associated with hotspot 624 is asserted and call a special instanceof helper 632 .
  • a special helper may be different from a normal helper in that the special helper may assert a bit indicator in an object header of an object in case of type checking success, for example, as shown in FIGS. 3 and 4 . Comparing with traversing the class hierarchy, checking a bit indicator in an object header may reduce the runtime type checking overhead. In another embodiment, one or more type checking hotspots with the same target class may share the same bit indicator and the same target class entry.
  • the program may use the following statement to create an instance of Child and assign to an reference (similar to a pointer) which has type Parent:
  • the program may do type casting and call Child's bar as follows:
  • the first compiler 130 may output the bytecode checkcast, for example, before assigning the ref to ref2 to do runtime checking so as to make sure the casting is safe (e.g., the object is an instance of the target class or the target class's sub class).
  • JVM 530 may be Implemented with dynamic compiler 534 , such as a Just-In-Time (JIT) compiler.
  • the dynamic compiler 534 may translate the byte codes from the first compiler 510 to architecture native codes that may be recognized by processor 110 .
  • dynamic compiler 534 may emit a call to a JVM 530 's helper function, e.g., checkcast helper or instanceof helper.
  • Processor 110 may use the function to do type checking and decide whether to throw an exception (for checkcast) or return the check status (for instanceof).
  • An example of bytecodes and translated native instructions may be as follows:
  • JVM 530 may use dynamic profiling to find hot places or hotspots, for example, in profiler 536 . Another optimized procedure may be used for these hot places by saving the type checking results of the hot places into an object header 200 .
  • dynamic compiler 534 may regenerate check codes for the hotspots. For example, if bit 0 in the object header is assigned for a hotspot, the following codes may be generated:

Abstract

Type checking between an object class and a target class may comprise getting an object header from an object, and checking from the object header a result of a first time type checking between a class of the object and a target class specified by a hotspot in the first time type checking.

Description

    BACKGROUND
  • Object-oriented programming languages may support inheritance, which may use an existing type to derive a new type. Derived types may inherit data and operations of super-type of the derived types; and they may overwrite existing operations or add new ones. Complex object-oriented programs may contain complex inheriting hierarchies. These hierarchies may often require that the program explicitly convert an object reference from one type to another type. This type of conversion may need run-time type checking that may be used to check whether the object is cast into an invalid target type. For most implementation of object-oriented programming languages, besides a memory to store fields of an object, each object may have an object header to provide basic services of object-oriented programming, such as class hierarchies with virtual methods, and other metadata that may be tapped into for different kinds of uses.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention described herein is illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.
  • FIG. 1 illustrates an embodiment of a system that may implement type checking.
  • FIG. 2 illustrates an embodiment of a data structure that may be used in the present invention.
  • FIG. 3 illustrates an embodiment of a checkcast process that may be used in type checking for an object-oriented programming language.
  • FIG. 4 illustrates an embodiment of an instanceof process that may be used in type checking for an object-oriented programming language.
  • FIG. 5 is a block diagram illustrating an embodiment of a system that may dynamically generate type checking code in a Java run-time environment.
  • FIG. 6 is a schematic diagram of a type checking related process according to an embodiment of the present invention.
  • DETAILED DESCRIPTION
  • The following description describes techniques to accelerate run-time type checking in Java virtual machine. The implementation of the techniques is not restricted in Java virtual machine; it may be used by any execution environments for similar purposes. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. However, the invention may be practiced without such specific details. In other instances, control structures and full software instruction sequences have not been shown in detail in order not to obscure the invention.
  • References in the specification to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • Embodiments of the invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.
  • FIG. 1 illustrates an example system that may implement the methods of the present invention. Referring to FIG. 1, in one embodiment, system 100 may comprise a processor 110. Processor 110 may coupled with a memory 120 via a bus 115. Processor 110 may be any type of processor adapted to execute instructions from memory 120. For example, processor 110 may be a microprocessor, a digital signal processor, a microcontroller, or the like.
  • In one embodiment, processor 110 and memory 120 may be included on an integrated circuit board, and bus 115 may be implemented using traces on the circuit board. In another embodiment, processor 110 and memory 120 may be included within the same integrated circuit, and bus 115 may be implemented using interconnect within the integrated circuit.
  • As shown in FIG. 1, in one embodiment, processor 110 may execute a first compiler 130. The first compiler 130 may comprise any type of compiler adapted to output instructions for type checking. For example, the first compiler 130 may comprise a Java compiler that may output Java byte codes for runtime checking. In another embodiment, processor 110 may execute a Java Virtual Machine (JVM) 140. For example, JVM 140 may be implemented with a Just-In-Time (JIT) compiler. JVM 140 may be coupled with the first compiler 130 to translate the Java byte codes outputted from the first compiler 130 to architecture specific native codes. In yet another embodiment, the first compiler 130 and/or JVM 140 may be implemented with software that may be stored in memory 120. In one embodiment, processor 110 may perform operations according to the instructions from JVM 140, for example, a process as shown in FIG. 3 or 4.
  • FIG. 3 illustrates a flowchart showing an embodiment of a method that may be used in type checking for an object-oriented programming language. The following description may be focused on Java that is one of the object-oriented programming languages; however, other embodiments may be used for other dynamically compiled object-oriented programming languages such as, for example, C#, Python, LISP, etc. In the example of Java, it may have one or more, e.g., five, conversion contexts in which conversion expression may occur. For example, an example conversion from type S to type T may allow an expression of Type S to be treated at compiling time as if it had type T instead. In some cases, to achieve type safety during conversion, a corresponding action may be made at run time to check the validity of the conversion. For example, for an object, a conversion from type “class Object” to type “class Thread” may need a run-time check to see if the object is an instance of class Thread or one of its subclass. In one embodiment, Java Virtual Machine 140 may use one or more byte codes or instructions, e.g., checkcast and instanceof, for performing type checking on an object.
  • Referring to FIG. 3, the method may be used for a checkcast process. In block 302, processor 110 may obtain an object header. In one embodiment, processor 110 may get the object header from an object handle of an object 200 as shown in FIG. 2. Referring to FIG. 2, In one embodiment, object header 205 may comprise one or more bits that may represent the class of the object. Numerical reference 220 may represent a data structure. For example, data structure 220 may be implemented as table, array, list or the like. In one embodiment, data structure 220 may comprise a target class table. In one embodiment, data structure 220 may comprise one or more entries that each may comprise a target class handle associated with a hotspot. In another embodiment, the data structure 220 may be dedicated to one object, or shared by one or more objects inside JVM 140. For example, numerical reference 230 may refer to a second object. The second object 230 may comprise a second object header 235 that may be obtained from a second object handle 2; however, other embodiments may comprise a different number of objects.
  • For example, processor 110 may use dynamic profiling to find out one or more hotspots, e.g., during program running. For example, a hotspot may refer to a hot check point that may be a location in a program at which the type checking operation from objects to a given target class occurs one or more times, e.g., a lot of times, during program running. The processor 110 may deduce a target class from a type checking hotspot. In one embodiment, target class handle 222 may contain class identification of a first target class; target class handle 224 may contain class identification of a second target class; and target class handle 226 may contain class identification of the nth target class; however, other embodiments may identify target classes with different information. In one embodiment, the method of FIG. 3 may be used for type checking associated with a hotspot. In another embodiment, one or more type checking hotspots with the same target class may share the same bit indicator of an object header and thus the same target class entry.
  • In one embodiment, the first object header 205 may allocate one or more bits 210 that each may correspond to an entry in data structure 220. Similarly, the second object header 235 may allocate each of one or more bits 240 to a corresponding entry in data structure 220. For example, bit 212 may be allocated to the first entry 222; bit 214 may be assigned to the second entry 224; and bit 242 may be assigned to the nth entry 226; however, other embodiments may allocate a bit for an entry in a different order. In one embodiment, JVM 140 may assert the one or more bits 210 in the first object header 205 and/or one or more bits 240 in the second object header 235 as indicators that may each indicate whether a type checking associated with a corresponding entry is successful. For example, the one or more bit indicators 210 and/or 240 may have a first logic value (for example, “0”) in their initial states. Processor 110 may assert a bit indicator 210 and/or 240 corresponding to an entry to a second logic value (for example, “1”), in response to determining that a type checking associated with the entry is successful.
  • In block 304, during performing a checkcast type checking for an object at a hotspot, processor 110 may check whether a bit indicator 210 in object header 205 of the object is asserted. For example, processor 110 may determine whether the bit indicator 210 that is allocated to a target class of the hotspot is asserted to a second logic value (for example, “1”). In response to the bit indicator 210 being asserted, processor 110 may determine that the type checking between the object class and the target class associated with the hotspot is successful and may terminate the type checking at the hotspot.
  • On the contrary, in block 306, JVM 140 may call a function that may be stored in memory 120 to perform a type checking for the object class, in response to determining that the bit indicator 210 is deasserted. For example, processor 110 may call the function, in response to determining that the bit indicator 210 has a first logic value or the bit indicator 210 is in its initial state. In one embodiment, the function may comprise a special checkcast helper, for example, with reference to blocks 308, 310, 312, 314, 316 and 318. In one embodiment, processor 110 may determine whether the object class of the current object and the target class match a predetermined criterion/condition.
  • In one embodiment, processor 110 may traverse the super classes of the class of the current object to see whether one of the super classes could be the same as the target class. For example, the type checking for the class of the current object is successful, in response to the processor 110 determining that one of the super classes is the same as the target class. In another embodiment, processor 110 may traverse a class hierarchy associated with the class of the current object to determine whether the target class is represented in the class hierarchy based on one or more predetermined criteria or conditions. For example, the processor 110 may determine that the type checking between the class of the current object and the target class is successful, in response to determining that the target class is represented in the class hierarchy.
  • In one embodiment, the class hierarchy may be implemented as an array of class references or the like that may be used to perform type checking in Java computing environments. In one embodiment, the class hierarchy may represent all the parent classes of Java classes in a hierarchical relationship. In another embodiment, an example of a predetermined criterion/condition is described as follows, wherein S=class of an object; T=target class:
  • I) If S is a nonarray class, then:
      • i) If T is a class type, then S must be the same class as T, or a subclass of T.
      • ii) If T is an interface type, then S must implement interface T.
  • II) If S is an interface type, then:
      • i) If T is a class type, then T must be Object.
      • ii) If T is an interface type, then T must be the same interface as S or a super interface of S.
  • III) If S is a class representing the array type SC□, then:
      • i) If T is a class type, then T must be Object.
      • ii) If T is an array type TC□, then one of the following must be true:
        • a) TC and SC are the same primitive type.
        • b) TC and SC are reference types, and type SC can be cast to TC by recursive application of these criteria.
      • iii) If T is an interface type, T must be one of the interfaces implemented by arrays.
  • In block 310, processor 110 may assert a bit indicator 210 in the object header of the current object to indicate that the type checking between the object class and the target class is successful. For example, processor 110 may assert the bit indicator 210 to a second logic value. In one embodiment, the bit indicator 210 may correspond to an entry in data structure 220 that represents a target class, for example, class handle, associated with a hotspot. Further, in block 312, processor 110 may return the result indicating that the type checking between the object class and the target class is successful or the object class and the target class matches a predetermined criterion/condition. For example, processor 110 may return “True”. In another embodiment, processor 110 may return a “True” result before asserting the bit indicator 210. Conversely, in response to determining that the class of the current object and the target class do not match the criterion/condition or the type checking fails, processor 110 may return a corresponding result, for example, “False” (block 314).
  • In block 316, processor 110 may determine whether the object has passed the type checking based upon the result returned in blocks 312 or 314. For example, in response to determining that the object has not passed the type checking based on a result “False” or a failure result, processor 110 may throw an exception (block 318). Conversely, in response to a pass result, e.g., “True”, the type checking flow of FIG. 3 is ended. In one embodiment, processor 110 may continue other operations of the system 100.
  • FIG. 4 is a flowchart illustrating a method according to another embodiment of the present invention. Referring to FIG. 4, the process of FIG. 4 is similar to that of FIG. 3 except blocks 406, 418 and 420. In particular, in block 406, processor 110 may call a function that may be stored in memory 120, in response to determining that a bit indicator 210 associated with a target class of a type checking hotspot has not been asserted. For example, processor 110 may call a special instanceof helper. In another embodiment, in block 418, processor 110 may push a first code, e.g., a True code, on an operand stack of memory 120 in response to determining that the object has passed the type checking. Conversely, in block 420, processor 110 may push a second code, e.g., a False code, on the operand stack in response to determining that the object has not passed the type checking.
  • Similar with 80-20 rule, the hot or hottest check points (using, e.g., either checkcast or instanceof bytecode), that consume most runtime on type checking may occur at several points (thus for several target classes). And, type checkings at one or more or most of the hot or hottest check points may be successful, e.g., in most cases. In one embodiment, the method as shown in FIG. 3 or 4 may be used for every such check point. For example, the JVM 140 may use dynamic profiling to find out hot check points that are either checkcast or instanceof bytecode, during the processor executing the Java program, in which the type checking are made using conventional methods.
  • While the methods of FIGS. 3 and 4 are illustrated as a sequence of operations, the illustrated operations may be performed in a different order in other embodiments.
  • FIG. 5 is a block diagram illustrating an embodiment of a system 500 that may execute Java program in, e.g., system 100. In one embodiment, the system 500 may be a Java runtime system. The system 500 may contain a dynamic compiler 534 that may translate the Java program's bytecode into instructions of the processor 110 that may be executed directly on processor 110. In one embodiment, the dynamic compiler 534 may dynamically generate type checking code.
  • As shown in FIG. 5, system 500 may comprise a first compiler 510 that may compile Java source code 502 to Java byte code 504. In one embodiment, the first compiler 510 may be itself a computer program. Referring to FIG. 5, a loader 532 may load the byte codes 504 into JVM 530. A dynamic compiler 534 in JVM 530 may turn the byte code 504 loaded via loader 532 into native code 508 associated with the program. In one embodiment, the dynamic compiler 534 may comprise a “just-in-time” (JIT) compiler or the like. In another embodiment, JVM 530 may comprise an interpreter to interpret the byte codes 504. In another embodiment, JVM 530 may comprise a profiler 536 that may perform dynamic profiling during the program running to detect one or more hot check points, i.e., hotspots, that may occur at several points (thus for several type classes) in a program. Profiler 536 may return the detected hotspots 506 to dynamic compiler 534.
  • FIG. 6 is a schematic diagram of a type checking related process 600 that may be generated by JVM 530. In one embodiment, block 610 may refer to the native instructions of processor 110 translated from Java bytecodes 504. In one embodiment, dynamic compiler 534 may use normal methods to generate type checking code at the first time compilation. For example, dynamic compiler 534 may generate type checking code to call normal checkcast helpers 612 and 616 and a normal instanceof helper 614 for the type checking; however, other embodiments may use different functions for type checking in a different order. The normal type checking helper may get a class of an object and traverse a class hierarchy to check whether the object class and target class meets a criteria, which may be time consuming. During program running based on type checking code generated during the first time compilation, profiler 536 may perform dynamic profiling to detect type checking hotspots, which may trigger a second time compilation for these hotspots in dynamic compiler 534. Referring to FIG. 6, profiler 536 may determine a hotspot 622 of the checkcast helper 612 and a hotspot 624 of the instanceof helper 614.
  • In one embodiment, during the second time compilation, dynamic compiler 534 may deduce a target class for a hotspot of checkcast or instanceof helper. For example, dynamic compiler 534 may deduce a target class for hotspots 622 and 624 that relates to a normal checkcast helper and a normal instanceof helper, respectively. Dynamic compiler 534 may allocate an entry in data structure 220 to save the target class handle of the deduced target class and a corresponding bit indicator in an object for the entry. Referring to FIG. 2, in one embodiment, one bit indicator 210 may comprise a bit in object header 205 of an object 200 (the bit may be cleared by default). Dynamic compiler 534 may regenerate type checking code (for example, block 630) to check the bit indicator 210 and call a special helper for the hotspot. In one embodiment, for hotspot 622, dynamic compiler 534 may regenerate type checking code to check whether a bit indicator associated with hotspot 622 is asserted and call a special checkcast helper 632. For hotspot 624, dynamic compiler 534 may regenerate type checking code to check whether a bit indicator associated with hotspot 624 is asserted and call a special instanceof helper 632. In one embodiment, a special helper may be different from a normal helper in that the special helper may assert a bit indicator in an object header of an object in case of type checking success, for example, as shown in FIGS. 3 and 4. Comparing with traversing the class hierarchy, checking a bit indicator in an object header may reduce the runtime type checking overhead. In another embodiment, one or more type checking hotspots with the same target class may share the same bit indicator and the same target class entry.
  • In the following, an embodiment of a program that may need runtime type checking is described. For example, it may be assumed that there are two classes, Parent and Child. The program, e.g., Java program, may use the following statements to define the two classes.
  • class Parent {
    void foo( ) { }
    }
    class Child extends Parent {
    void foo( ) { }
    void bar( ) { }
    }
  • In one embodiment, the program may use the following statement to create an instance of Child and assign to an reference (similar to a pointer) which has type Parent:
      • Parent ref=new Child( );
  • In another embodiment, the program may do type casting and call Child's bar as follows:
      • Child ref2=(Child) ref;
        • ref2.bar( );
  • The first compiler 130 may output the bytecode checkcast, for example, before assigning the ref to ref2 to do runtime checking so as to make sure the casting is safe (e.g., the object is an instance of the target class or the target class's sub class).
  • In another embodiment, in the implementation 500, JVM 530 may be Implemented with dynamic compiler 534, such as a Just-In-Time (JIT) compiler. For example, the dynamic compiler 534 may translate the byte codes from the first compiler 510 to architecture native codes that may be recognized by processor 110. For checkcast & instanceof, dynamic compiler 534 may emit a call to a JVM 530's helper function, e.g., checkcast helper or instanceof helper. Processor 110 may use the function to do type checking and decide whether to throw an exception (for checkcast) or return the check status (for instanceof). An example of bytecodes and translated native instructions may be as follows:
  • checkcast Child
    ldr r0, [sp] // get the object reference
    mov r1, #0x5a3200 // the target class
    bl 0x69d268 // call checkcast helper with object
    reference and target class
  • In the example of a Java program, sometimes only several type checking may be hot. After dynamic compiler 534 completes the first time compilation, JVM 530 may use dynamic profiling to find hot places or hotspots, for example, in profiler 536. Another optimized procedure may be used for these hot places by saving the type checking results of the hot places into an object header 200. In one embodiment, dynamic compiler 534 may regenerate check codes for the hotspots. For example, if bit 0 in the object header is assigned for a hotspot, the following codes may be generated:
  • checkcast Child
    ldr r0, [sp] // get object reference
    ldr r2, [r0] // get object header (the header has the
    information on object class, etc.)
    tst r2, #0x1 // check if bit 0 is asserted
    bne check_done // if asserted, then this object has been
    checked in this site, and the previous check is successful,
    // skip the helper call
    mov r1, #0x5a3200 // the target class
    bl 0x69d268 // call check helper with object reference
    and target class
    check_done:
    . . .
  • While certain features of the invention have been described with reference to embodiments, the description is not intended to be construed in a limiting sense. Various modifications of the embodiments, as well as other embodiments of the invention, which are apparent to persons skilled in the art to which the invention pertains are deemed to lie within the spirit and scope of the invention.

Claims (30)

1. A method comprising
getting an object header from an object, and
checking from the object header a result of a first time type checking between a class of the object and a target class specified by a hotspot in the first time type checking.
2. The method of claim 1 further comprising
determining whether the object header comprises an indicator that is asserted to indicate a first time type checking success between the object class and the target class associated with the indicator.
3. The method of claim 1 further comprising
determining whether the object header comprises an indicator that is deasserted to indicate a first time type checking failure between the object class and the target class associated with the indicator.
4. The method of claim 1 further comprising
skipping a second time type checking between the object class and the target class, in response to determining that the object header comprises an indicator that is asserted to indicate a first time type checking success.
5. The method of claim 1 further comprising
performing a second time type checking between the object class and the target class, in response to determining that the object header comprises an indicator that is deasserted to indicate a first time type checking failure.
6. The method of claim 1 further comprising
detecting the hotspot in the first time type checking by dynamic profiling.
7. A system, comprising
a processor to get an object header from an object, and obtain from the object header a result of a first time type checking at a hotspot between a class of the object and a target class specified by the hotspot; and
a memory to save the target class.
8. The system of claim 7, wherein the processor further to
determine that the first time type checking at the hotspot is successful, in response to detecting that the object header comprises an indicator associated with the target class that has a first logic value.
9. The system of claim 7, wherein the processor further to
perform a second time type checking between the object class and the target class, in response to detecting that an indicator associated with the target class in the object header has a second logic value.
10. The system of claim 7, wherein the processor further to
traverse a class hierarchy associated with the class of the object, in response to determining that the first time type checking at the hotspot is failed.
11. The system of claim 7, wherein the processor further to
assert an indicator associated with the target class in the object header, in response to determining in a second time type checking at the hotspot that the class of the object and the target class match a type checking condition.
12. The system of claim 7, wherein the processor further to
return a signal indicating that the type checking is successful, in response to determining that the class of the object and the target class match a predetermined criterion.
13. The system of claim 7, wherein the memory further to save a beginning address of a handle of the target class, and wherein the processor further to detecting the hotspot by dynamic profiling.
14. A machine readable medium comprising a plurality of instructions that in response to being executed result in a computing device
obtaining an object header from an object, and
checking a bit indicator in the object header to indicate a result of a first time type checking at a hotspot between a class of the object and a target class specified by the hotspot.
15. The machine readable medium of claim 14, wherein the machine readable medium further comprising Instructions that in response to being executed result in the computing device
skipping a second time type checking at the hotspot between the object class and the target class, in response to determining that the bit indicator is asserted to indicate a successful result.
16. The machine readable medium of claim 14, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
performing a second time type checking at the hotspot between the object class and the target class, in response to determining that the bit indicator is deasserted to indicate a failure result.
17. The machine readable medium of claim 14, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
detecting at the hotspot whether the object class and the target class match a type checking criterion, in response to determining that the bit indicator indicates a failure result.
18. The machine readable medium of claim 16, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
asserting the bit indicator, in response to determining in the second time type checking that the object class and the target class match a type checking criterion.
19. The machine readable medium of claim 16, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
returning a signal indicating a result of the second time type checking.
20. The machine readable medium of claim 16, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
throwing an exception, in response to determining that the second time type checking is successful.
21. The machine readable medium of claim 16, wherein the machine readable medium further comprising instructions that in response to being executed result in the computing device
pushing a result code on a stack to indicate whether the type checking is successful.
22. A system comprising,
a compiler to convert source code associated with a first time type checking for an object into byte code;
a loader coupled with the compiler to load the byte code;
a dynamic compiler coupled with the loader to receive the byte code from the loader, and to generate first native code associated with the first time type checking based on the byte code; and
a profiler coupled with the dynamic compiler to detect a hotspot in the first time type checking based on the first native code, and to return the hotspot to the dynamic compiler.
23. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to determine a type checking result between a class of the object and a target class specified by the hotspot from an object header of the object.
24. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to detect a type checking success between a class of the object and a target class specified by the hotspot, in response to determining that an indicator associated with the target class in an object header of the object has a first logic value.
25. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to detect a type checking failure between a class of the object and a target class specified by the hotspot, in response to determining that an indicator associated with the target class in an object header of the object has a second logic value.
26. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to skip type checking between a class of the object and a target class specified by the hotspot, in response to determining that an object header of the object indicates a type check success.
27. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to perform type checking between a class of the object and a target class specified by the hotspot, in response to determining that an indicator associated with the target class in an object header of the object is deasserted.
28. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to assert an indicator in an object header of the object, in response to a type checking success between a class of the object and a target class specified by the hotspot.
29. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to traverse super classes of a class of the object to determine whether one of the super classes is the same as a target class as specified by the hotspot, in response to determining a type checking failure between the class of the object and the target class from an object header of the object.
30. The system of claim 22, wherein the dynamic compiler further to regenerate second native code that calls a type checking function for the hotspot to traverse a class hierarchy associated with a class of the object to determine whether a target class as specified by the hotspot is represented in the class hierarchy, in response to determining a type checking failure between the class of the object and the target class from an object header of the object.
US10/583,648 2005-12-30 2005-12-30 Type checking for object-oriented programming languages Expired - Fee Related US9009688B2 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2005/002403 WO2007076629A1 (en) 2005-12-30 2005-12-30 Type checking for object-oriented programming languages

Publications (2)

Publication Number Publication Date
US20090150863A1 true US20090150863A1 (en) 2009-06-11
US9009688B2 US9009688B2 (en) 2015-04-14

Family

ID=38227886

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/583,648 Expired - Fee Related US9009688B2 (en) 2005-12-30 2005-12-30 Type checking for object-oriented programming languages

Country Status (2)

Country Link
US (1) US9009688B2 (en)
WO (1) WO2007076629A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090150875A1 (en) * 2007-12-05 2009-06-11 International Business Machines Corporation Efficient object profiling for optimizing object locality
US20090171625A1 (en) * 2008-01-02 2009-07-02 Beehive Engineering Systems, Llc Statement-Based Computing System
US20090319991A1 (en) * 2008-06-20 2009-12-24 Microsoft Corporation Managed code type equivalence
US20130212567A1 (en) * 2012-02-13 2013-08-15 Microsoft Corporation Generating and caching software code
US20130263099A1 (en) * 2008-10-03 2013-10-03 Microsoft Corporation Common intermediate representation for data scripting language
US8732670B1 (en) 2010-06-29 2014-05-20 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US8769518B1 (en) * 2010-06-29 2014-07-01 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US8909722B2 (en) 2007-03-07 2014-12-09 True Engineering Technology, Llc System and method of supporting constructive discourse on computers and mobile devices
US20160196114A1 (en) * 2014-09-16 2016-07-07 International Business Machines Corporation Apparatus and method for realizing runtime system for programming language
US9524175B2 (en) 2012-11-14 2016-12-20 Oracle International Corporation Target typing of overloaded method and constructor arguments
US20180276015A1 (en) * 2015-12-02 2018-09-27 Huawei Technologies Co, Ltd. Method and apparatus for identifying hotspot intermediate code in language virtual machine

Citations (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4788637A (en) * 1985-09-30 1988-11-29 Kabushiki Kaisha Toshiba Communication control apparatus
US5847953A (en) * 1996-09-23 1998-12-08 National Instruments Corporation System and method for performing class checking of objects in a graphical data flow program
US5930807A (en) * 1997-04-23 1999-07-27 Sun Microsystems Apparatus and method for fast filtering read and write barrier operations in garbage collection system
US5978581A (en) * 1997-12-02 1999-11-02 Electronic Data Systems Corporation Object-oriented code generation system and method
US6058396A (en) * 1997-02-06 2000-05-02 Sterling Software, Inc. Product interface method and system which allow class evolution
US6064816A (en) * 1996-09-23 2000-05-16 National Instruments Corporation System and method for performing class propagation and type checking in a graphical automation client
US6081665A (en) * 1997-12-19 2000-06-27 Newmonics Inc. Method for efficient soft real-time execution of portable byte code computer programs
US6138269A (en) * 1998-05-20 2000-10-24 Sun Microsystems, Inc. Determining the actual class of an object at run time
US6151703A (en) * 1996-05-20 2000-11-21 Inprise Corporation Development system with methods for just-in-time compilation of programs
US6212608B1 (en) * 1996-11-04 2001-04-03 Sun Microsystems, Inc. Method and apparatus for thread synchronization in an object-based system
US6289506B1 (en) * 1998-06-30 2001-09-11 Intel Corporation Method for optimizing Java performance using precompiled code
US6317872B1 (en) * 1997-07-11 2001-11-13 Rockwell Collins, Inc. Real time processor optimized for executing JAVA programs
US20020037006A1 (en) * 2000-07-25 2002-03-28 Broadcom Corporation Hardware assist for address learning
US6381734B1 (en) * 1998-06-03 2002-04-30 Microsoft Corporation Method, software and apparatus for referencing a method in object-based programming
US20020108107A1 (en) * 1998-11-16 2002-08-08 Insignia Solutions, Plc Hash table dispatch mechanism for interface methods
US6453463B1 (en) * 1999-06-07 2002-09-17 Sun Microsystems, Inc. Method and apparatus for providing finer marking granularity for fields within objects
US6484188B1 (en) * 1999-12-30 2002-11-19 Intel Corporation Optimization of garbage collection code in the context of raw native interface function calls in the java programming language
US20030079201A1 (en) * 2001-10-24 2003-04-24 Sun Microsystems, Inc. Type checking in java computing environments
US6557023B1 (en) * 1999-05-28 2003-04-29 Sun Microsystems, Inc. Method and apparatus for avoiding array class creation in virtual machines
US20040003380A1 (en) * 2002-06-26 2004-01-01 Microsoft Corporation Single pass intermediate language verification algorithm
US6681381B1 (en) * 1999-01-06 2004-01-20 Koninklijke Philips Electronics N.V. Arrangement for executing program code with reduced memory requirements
US20040015918A1 (en) * 2001-02-28 2004-01-22 Motohiro Kawahito Program optimization method and compiler using the program optimization method
US6694507B2 (en) * 2000-12-15 2004-02-17 International Business Machines Corporation Method and apparatus for analyzing performance of object oriented programming code
US20040103391A1 (en) * 2002-11-27 2004-05-27 Gansha Wu Software object type identification apparatus and methods
US6760907B2 (en) * 1998-06-30 2004-07-06 Sun Microsystems, Inc. Code generation for a bytecode compiler
US20040205750A1 (en) * 2003-04-08 2004-10-14 Sun Microsystems, Inc., A Delaware Corporation Fingerprint subtype checking
US20040205701A1 (en) * 2000-03-16 2004-10-14 International Business Machines Corporation Computer system, virtual machine, runtime representation of object, storage media and program transmission apparatus
US6865730B1 (en) * 2000-03-08 2005-03-08 International Business Machines Corporation Interprocedural analysis and optimization of an object oriented program in the presence of dynamic class loading
US20050071810A1 (en) * 2003-09-29 2005-03-31 International Business Machines Corporation Automatic customization of classes
US20050071826A1 (en) * 2003-09-30 2005-03-31 International Business Machines Corporation Determining how many class-type checks to inline
US6912542B2 (en) * 2001-09-26 2005-06-28 Intel Corporation Method for implementing fast type checking
US7080354B2 (en) * 2002-03-29 2006-07-18 Intel Corporation Method for implementing dynamic type checking
US20060212847A1 (en) * 2005-03-18 2006-09-21 Microsoft Corporation Type checker for a typed intermediate representation of object-oriented languages
US20060253503A1 (en) * 2005-05-05 2006-11-09 International Business Machines Corporation Method and apparatus for aging a versioned heap system
US20060253845A1 (en) * 2005-05-03 2006-11-09 International Business Machines Corporation Method and apparatus for determining leaks in a Java heap
US7200842B1 (en) * 1999-02-02 2007-04-03 Sun Microsystems, Inc. Object-oriented instruction set for resource-constrained devices
US7210122B2 (en) * 2001-03-22 2007-04-24 International Business Machines, Corporation Method for reducing write barrier overhead
US20070277021A1 (en) * 1996-01-24 2007-11-29 Sun Microsystems, Inc. Instruction folding for a stack-based machine
US7373639B2 (en) * 1999-11-01 2008-05-13 Sumisho Computer Systems Corporation System and method supporting type checking of options
US20090031292A1 (en) * 2007-07-24 2009-01-29 Mike Stephen Fulton Copy-on-write optimization of immutable objects for object oriented languages
US20090064114A1 (en) * 2007-08-31 2009-03-05 International Business Machines Corporation Systems, methods, and computer products for automated injection of java bytecode instructions for java load time optimization via runtime checking with upcasts
US7831640B2 (en) * 2008-04-15 2010-11-09 Microsoft Corporation Using an overflow list to process mark overflow
US20120054725A1 (en) * 2010-08-31 2012-03-01 International Business Machines Corporation method and system for code generation and inlining
US8495427B2 (en) * 2009-10-14 2013-07-23 International Business Machines Corporation Detecting defects in deployed systems

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567973B1 (en) * 1999-07-28 2003-05-20 International Business Machines Corporation Introspective editor system, program, and method for software translation using a facade class
WO2001057656A2 (en) * 2000-02-07 2001-08-09 Insignia Solutions Plc Reduced size object headers

Patent Citations (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4788637A (en) * 1985-09-30 1988-11-29 Kabushiki Kaisha Toshiba Communication control apparatus
US20070277021A1 (en) * 1996-01-24 2007-11-29 Sun Microsystems, Inc. Instruction folding for a stack-based machine
US6151703A (en) * 1996-05-20 2000-11-21 Inprise Corporation Development system with methods for just-in-time compilation of programs
US5847953A (en) * 1996-09-23 1998-12-08 National Instruments Corporation System and method for performing class checking of objects in a graphical data flow program
US6064816A (en) * 1996-09-23 2000-05-16 National Instruments Corporation System and method for performing class propagation and type checking in a graphical automation client
US6510437B1 (en) * 1996-11-04 2003-01-21 Sun Microsystems, Inc. Method and apparatus for concurrent thread synchronization
US6212608B1 (en) * 1996-11-04 2001-04-03 Sun Microsystems, Inc. Method and apparatus for thread synchronization in an object-based system
US6058396A (en) * 1997-02-06 2000-05-02 Sterling Software, Inc. Product interface method and system which allow class evolution
US5930807A (en) * 1997-04-23 1999-07-27 Sun Microsystems Apparatus and method for fast filtering read and write barrier operations in garbage collection system
US6317872B1 (en) * 1997-07-11 2001-11-13 Rockwell Collins, Inc. Real time processor optimized for executing JAVA programs
US5978581A (en) * 1997-12-02 1999-11-02 Electronic Data Systems Corporation Object-oriented code generation system and method
US6081665A (en) * 1997-12-19 2000-06-27 Newmonics Inc. Method for efficient soft real-time execution of portable byte code computer programs
US6138269A (en) * 1998-05-20 2000-10-24 Sun Microsystems, Inc. Determining the actual class of an object at run time
US6381734B1 (en) * 1998-06-03 2002-04-30 Microsoft Corporation Method, software and apparatus for referencing a method in object-based programming
US6289506B1 (en) * 1998-06-30 2001-09-11 Intel Corporation Method for optimizing Java performance using precompiled code
US6760907B2 (en) * 1998-06-30 2004-07-06 Sun Microsystems, Inc. Code generation for a bytecode compiler
US20020108107A1 (en) * 1998-11-16 2002-08-08 Insignia Solutions, Plc Hash table dispatch mechanism for interface methods
US7058929B2 (en) * 1998-11-16 2006-06-06 Esmertec Ag Direct invocation of methods using class loader
US6681381B1 (en) * 1999-01-06 2004-01-20 Koninklijke Philips Electronics N.V. Arrangement for executing program code with reduced memory requirements
US7200842B1 (en) * 1999-02-02 2007-04-03 Sun Microsystems, Inc. Object-oriented instruction set for resource-constrained devices
US6557023B1 (en) * 1999-05-28 2003-04-29 Sun Microsystems, Inc. Method and apparatus for avoiding array class creation in virtual machines
US6453463B1 (en) * 1999-06-07 2002-09-17 Sun Microsystems, Inc. Method and apparatus for providing finer marking granularity for fields within objects
US7373639B2 (en) * 1999-11-01 2008-05-13 Sumisho Computer Systems Corporation System and method supporting type checking of options
US6484188B1 (en) * 1999-12-30 2002-11-19 Intel Corporation Optimization of garbage collection code in the context of raw native interface function calls in the java programming language
US6865730B1 (en) * 2000-03-08 2005-03-08 International Business Machines Corporation Interprocedural analysis and optimization of an object oriented program in the presence of dynamic class loading
US6886159B2 (en) * 2000-03-16 2005-04-26 International Business Machines Corporation Computer system, virtual machine, runtime representation of object, storage media and program transmission apparatus
US20040205701A1 (en) * 2000-03-16 2004-10-14 International Business Machines Corporation Computer system, virtual machine, runtime representation of object, storage media and program transmission apparatus
US20020037006A1 (en) * 2000-07-25 2002-03-28 Broadcom Corporation Hardware assist for address learning
US6694507B2 (en) * 2000-12-15 2004-02-17 International Business Machines Corporation Method and apparatus for analyzing performance of object oriented programming code
US20040015918A1 (en) * 2001-02-28 2004-01-22 Motohiro Kawahito Program optimization method and compiler using the program optimization method
US7210122B2 (en) * 2001-03-22 2007-04-24 International Business Machines, Corporation Method for reducing write barrier overhead
US6912542B2 (en) * 2001-09-26 2005-06-28 Intel Corporation Method for implementing fast type checking
EP1310865A2 (en) * 2001-10-24 2003-05-14 Sun Microsystems, Inc. Type checking in Java computing environments
US20030079201A1 (en) * 2001-10-24 2003-04-24 Sun Microsystems, Inc. Type checking in java computing environments
US6948156B2 (en) * 2001-10-24 2005-09-20 Sun Microsystems, Inc. Type checking in java computing environments
US7080354B2 (en) * 2002-03-29 2006-07-18 Intel Corporation Method for implementing dynamic type checking
US20040003380A1 (en) * 2002-06-26 2004-01-01 Microsoft Corporation Single pass intermediate language verification algorithm
US20040103391A1 (en) * 2002-11-27 2004-05-27 Gansha Wu Software object type identification apparatus and methods
US7272828B2 (en) * 2002-11-27 2007-09-18 Intel Corporation Software object type identification
US20040205750A1 (en) * 2003-04-08 2004-10-14 Sun Microsystems, Inc., A Delaware Corporation Fingerprint subtype checking
US7356802B2 (en) * 2003-09-29 2008-04-08 International Business Machines Corporation Automatic customization of classes
US20050071810A1 (en) * 2003-09-29 2005-03-31 International Business Machines Corporation Automatic customization of classes
US20050071826A1 (en) * 2003-09-30 2005-03-31 International Business Machines Corporation Determining how many class-type checks to inline
US7266813B2 (en) * 2003-09-30 2007-09-04 International Business Machines Corporation Determining how many class-type checks to inline
US20060212847A1 (en) * 2005-03-18 2006-09-21 Microsoft Corporation Type checker for a typed intermediate representation of object-oriented languages
US20060253845A1 (en) * 2005-05-03 2006-11-09 International Business Machines Corporation Method and apparatus for determining leaks in a Java heap
US7870170B2 (en) * 2005-05-03 2011-01-11 International Business Machines Corporation Method and apparatus for determining leaks in a Java heap
US20060253503A1 (en) * 2005-05-05 2006-11-09 International Business Machines Corporation Method and apparatus for aging a versioned heap system
US20090031292A1 (en) * 2007-07-24 2009-01-29 Mike Stephen Fulton Copy-on-write optimization of immutable objects for object oriented languages
US20090064114A1 (en) * 2007-08-31 2009-03-05 International Business Machines Corporation Systems, methods, and computer products for automated injection of java bytecode instructions for java load time optimization via runtime checking with upcasts
US7831640B2 (en) * 2008-04-15 2010-11-09 Microsoft Corporation Using an overflow list to process mark overflow
US8495427B2 (en) * 2009-10-14 2013-07-23 International Business Machines Corporation Detecting defects in deployed systems
US20120054725A1 (en) * 2010-08-31 2012-03-01 International Business Machines Corporation method and system for code generation and inlining

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Alpern et al., Dynamic Type Checking in Jalapeno, Proceedings of The Java Virtual Machine Research and Technology Symposium, published 2001, pages 1-11 *

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9276888B2 (en) 2007-03-07 2016-03-01 True Engineering Technology, Llc System and method of supporting constructive discourse on computers and mobile devices
US8909722B2 (en) 2007-03-07 2014-12-09 True Engineering Technology, Llc System and method of supporting constructive discourse on computers and mobile devices
US8612956B2 (en) * 2007-12-05 2013-12-17 International Business Machines Corporation Efficient object profiling for optimizing object locality
US20090150875A1 (en) * 2007-12-05 2009-06-11 International Business Machines Corporation Efficient object profiling for optimizing object locality
US20090171625A1 (en) * 2008-01-02 2009-07-02 Beehive Engineering Systems, Llc Statement-Based Computing System
US9779082B2 (en) * 2008-01-02 2017-10-03 True Engineering Technology, Llc Portable self-describing representations of measurements
US20090319991A1 (en) * 2008-06-20 2009-12-24 Microsoft Corporation Managed code type equivalence
US9229696B2 (en) * 2008-10-03 2016-01-05 Microsoft Technology Licensing, Llc Common intermediate representation for data scripting language
US20130263099A1 (en) * 2008-10-03 2013-10-03 Microsoft Corporation Common intermediate representation for data scripting language
US8732670B1 (en) 2010-06-29 2014-05-20 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US10489168B2 (en) 2010-06-29 2019-11-26 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US8769518B1 (en) * 2010-06-29 2014-07-01 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US10585796B2 (en) 2010-06-29 2020-03-10 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US9542210B2 (en) 2010-06-29 2017-01-10 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US9606820B2 (en) 2010-06-29 2017-03-28 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US10083046B2 (en) 2010-06-29 2018-09-25 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US9110751B2 (en) * 2012-02-13 2015-08-18 Microsoft Technology Licensing, Llc Generating and caching software code
US20130212567A1 (en) * 2012-02-13 2013-08-15 Microsoft Corporation Generating and caching software code
US20150324183A1 (en) * 2012-02-13 2015-11-12 Microsoft Technology Licensing, Llc Generating and caching software code
US9940120B2 (en) * 2012-02-13 2018-04-10 Microsoft Technology Licensing, Llc Generating and caching software code
US9524175B2 (en) 2012-11-14 2016-12-20 Oracle International Corporation Target typing of overloaded method and constructor arguments
US9921858B2 (en) * 2014-09-16 2018-03-20 International Business Machines Corporation Apparatus and method for realizing runtime system for programming language
US10331465B2 (en) 2014-09-16 2019-06-25 International Business Machines Corporation Apparatus and method for realizing runtime system for programming language
US20160196114A1 (en) * 2014-09-16 2016-07-07 International Business Machines Corporation Apparatus and method for realizing runtime system for programming language
US10922107B2 (en) 2014-09-16 2021-02-16 International Business Machines Corporation Apparatus and method for realizing runtime system for programming language
US20180276015A1 (en) * 2015-12-02 2018-09-27 Huawei Technologies Co, Ltd. Method and apparatus for identifying hotspot intermediate code in language virtual machine
US10871976B2 (en) * 2015-12-02 2020-12-22 Huawei Technologies Co, Ltd. Method and apparatus for identifying hotspot intermediate code in language virtual machine

Also Published As

Publication number Publication date
WO2007076629A1 (en) 2007-07-12
US9009688B2 (en) 2015-04-14

Similar Documents

Publication Publication Date Title
US9009688B2 (en) Type checking for object-oriented programming languages
US9524163B2 (en) Computer processor employing hardware-based pointer processing
US6530075B1 (en) JIT/compiler Java language extensions to enable field performance and serviceability
US10324741B2 (en) Speeding up dynamic language execution on a virtual machine with type speculation
KR101143214B1 (en) Method and system for detecting potential races in multithreaded program
US7058929B2 (en) Direct invocation of methods using class loader
US8479050B2 (en) Identifying access states for variables
JP3533294B2 (en) Processor system
US7269718B2 (en) Method and apparatus for verifying data types to be used for instructions and casting data types if needed
US7647457B2 (en) Method and apparatus for hardware awareness of data types
US20100192026A1 (en) Implementations of program runtime checks
KR20000057010A (en) A method and apparatus to selectively control processing of a method in a java virtual machine
US6658657B1 (en) Method and apparatus for reducing the overhead of virtual method invocations
US7496897B1 (en) Multiple code sets for multiple execution contexts
US6714991B1 (en) Method and apparatus for implementing fast subclass and subtype checks
EP3084598B1 (en) Execution guards in dynamic programming
Pechtchanski et al. Dynamic optimistic interprocedural analysis: A framework and an application
US7328374B2 (en) Method and apparatus for implementing assertions in hardware
Male et al. Java bytecode verification for@ NonNull types
US11204767B2 (en) Context switching locations for compiler-assisted context switching
US20050251706A1 (en) Method and apparatus for data-aware hardware operations
Kreindl et al. Dynamic taint analysis with label-defined semantics
Vijaykrishnan et al. Tuning Branch Predictors to Support Virtual Method Invocation in Java.
US10521200B2 (en) Unambiguous proxying of interface methods
Almajali et al. Coupling availability and efficiency for aspect oriented runtime weaving systems

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTEL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GUO, PENG;SHI, XIAOHUA;REEL/FRAME:018020/0561

Effective date: 20060509

FEPP Fee payment procedure

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20190414