Extended virtual machine instruction set architecture

Abstract

The present invention relates to an extended virtual machine instruction set architecture. Operations include a compilation process and a runtime process. The compiler compiles code to generate virtual machine instructions. The compiler further generates information referencing corresponding parameter types of parameters of target virtual machine instructions. The compiler stores the information externally to the target virtual machine instructions and in association with the target virtual machine instructions. The information may be included in another virtual machine instruction preceding the target virtual machine instructions. The runtime environment processes the target virtual machine instructions based on the information stored externally to the target virtual machine instructions and in association with the target virtual machine instructions. The parameter types referenced by the external information override parameter types that are (a) referenced by the target virtual machine instructions themselves, (b) inferred by the runtime environment, and / or (c) directly stored in association with the parameter values.

Description

[0001] This application is a divisional application of the PCT application entering the Chinese national phase, with the international application date of July 28, 2016, national application number 201680046654.5, and invention name “Extended Virtual Machine Instruction Set Architecture”. Technical Field

[0002] The present disclosure relates to extending a virtual machine instruction set architecture. Specifically, the present disclosure relates to information (a) stored externally and associated with a virtual machine instruction and (b) referencing parameter types of parameters of the virtual machine instruction.

[0003] Rights and interests requirements

[0004] This application claims the benefit of and priority to U.S. Provisional Application No. 62 / 202,909, filed August 9, 2015, and U.S. Non-Provisional Application No. 15 / 005,448, filed January 25, 2016.

[0005] Incorporated by Reference

[0006] This application hereby incorporates by reference each of the following patent applications, as if included herein by reference:

[0007] (a) Application 62 / 202,909, filed August 9, 2015, entitled “Extending A Virtual Machine Instruction Set Architecture”;

[0008] (b) Application 15 / 005,448, filed January 25, 2016, entitled “Extending A Virtual Machine Instruction Set Architecture”;

[0009] (c) Application 14 / 699,141, entitled “Speeding Up Dynamic Language Execution on a Virtual Machine with Type Speculation,” filed April 29, 2015;

[0010] (d) Application 14 / 699,129, filed April 29, 2015, entitled “Handling Value Types”;

[0011] (e) Application 14 / 660,143, filed March 17, 2015, entitled “Metadata-Driven Dynamic Specialization”;

[0012] (f) Application 14 / 660,177, filed March 17, 2015, entitled “Structural identification of Dynamically Generated, Pattern-Instantiation, Generated Classes.”

[0013] (g) Application 14 / 660,604, entitled “Decomposing a Generic Class into Layers,” filed on March 17, 2015;

[0014] (h) Application No. 14 / 685,386, filed April 13, 2015, entitled “Target Typing-dependent Combinatorial Code Analysis”;

[0015] (i) Application 14 / 692,590, entitled “Dependency-driven Co-Specialization of Specialized Classes,” filed on April 21, 2015;

[0016] (j) Application No. 14 / 692,592, filed April 21, 2015, entitled “Partial Specialization of Generic Classes”;

[0017] (k) Application 14 / 692,593, filed April 21, 2015, entitled “Manual Refinement of Specialized Classes”;

[0018] (l) Application 14 / 692,601, filed on April 21, 2015, entitled “Wholesale Replacement of Specialized Classes”; and

[0019] (m) Application 14 / 743,912, filed June 18, 2015, entitled “Optimistically Assuming Types in a Dynamically Typed Language.” Background Art

[0020] An instruction set or instruction set architecture (ISA) is the part of a computer's architecture that is relevant for programming, including native data types, instructions, registers, addressing modes, memory architecture, interrupt and exception handling, and external I / O. An ISA includes a specification of a set of opcodes (machine language) and the native commands implemented by a specific processor.

[0021] Java bytecode is an instruction set for the Java Virtual Machine (JVM) generated by a compiler (e.g., the javac compiler). Each bytecode consists of one or, in some cases, two bytes representing an instruction (opcode) and zero or more bytes for passing parameters. Some opcodes are applicable to specific parameter types. For example, opcode "60" (mnemonic "iadd") adds two integer type values. In another example, opcode "62" (mnemonic "fadd") adds two floating point type values. Details about the structure of the JVM are included in Appendix A, which is included with this document. Details about the JVM instruction set are included in Appendix B, which is included with this document.

[0022] An optimizing compiler is a compiler that minimizes or maximizes some property of an executable computer program. For example, an optimizing compiler can be configured to increase runtime performance or reduce the amount of memory used by the program. Compiler optimization is typically implemented using a series of optimizing transformations, which are algorithms that take a program and transform it to produce a semantically equivalent output program that uses fewer resources or executes faster. Compiler optimization can be divided into several categories, such as loop optimization, data flow optimization, SSA-based optimization, code generator optimization, bounds check elimination, dead code restriction, etc.

[0023] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In the figures of the accompanying drawings, embodiments are illustrated by way of example and not limitation. It should be noted that references to "an embodiment" or "one embodiment" in this disclosure do not necessarily refer to the same embodiment, and they mean at least one. In the drawings:

[0025] Figure 1 An example computing architecture is illustrated in which the techniques described herein may be practiced.

[0026] Figure 2is a block diagram illustrating one embodiment of a computer system suitable for implementing the methods and features described herein.

[0027] Figure 3 Illustrated is an example virtual machine memory layout in block diagram form in accordance with one or more embodiments.

[0028] Figure 4 Illustrated are example frames in block diagram form in accordance with one or more embodiments.

[0029] Figure 5 Bytecode according to one or more embodiments is illustrated.

[0030] Figure 6 Illustrated is a set of operations for processing virtual machine instructions in accordance with one or more embodiments.

[0031] Figure 7 A system according to one or more embodiments is shown. DETAILED DESCRIPTION

[0032] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagram form in order to avoid unnecessarily obscuring the present invention.

[0033] 1. General Overview

[0034] 2. System Architecture Overview

[0035] 2.1 Example class file structure

[0036] 2.2 Example Virtual Machine Architecture

[0037] 2.3 Loading, Linking, and Initialization

[0038] 3. Extended virtual machine instruction set architecture

[0039] 3.1 Reference to parameter types of virtual machine instructions

[0040] 3.2 Processing virtual machine instructions based on external reference parameter types

[0041] 3.3 Example use of referenced parameter types

[0042] 4. Other; Extension

[0043] 5. Hardware Overview

[0044] 1. General Overview

[0045] Embodiments relate to the generation and use of information about parameter types of parameters of target virtual machine instructions. This information can reference a variable corresponding to a type value stored at a specific location (e.g., index) in a constant pool. The variable can correspond to a MethodHandle associated with a method that returns a type value. The type value is not necessarily known when generating information about the reference variable.

[0046] In an embodiment, the compiler generates the above information during the code compilation process. The compiler may store the information within the same set of bytecodes that includes the target virtual machine instructions. Specifically, the compiler may generate bytecodes that include (a) the target virtual machine instructions and (b) information stored outside the target virtual machine instructions and stored in association with the target virtual machine instructions. As an example, the information may be included in another virtual machine instruction that precedes the target virtual machine instruction within the same set of bytecodes.

[0047] In an embodiment, a runtime environment processes a target virtual machine instruction having one or more parameters based on corresponding parameter types referenced by information stored external to and associated with the target virtual machine instruction. As an example, the runtime environment selects a number of bytes from a data structure to be used to execute the target virtual machine instruction based on the parameter types. The runtime environment can process bytecodes that include both (a) virtual machine instructions associated with such information (referencing parameter types) and (b) virtual machine instructions not associated with such information.

[0048] The same virtual machine instruction can be processed differently by the runtime environment depending on whether the virtual machine instruction is associated with external information that references parameter types. Parameter types referenced by information stored external to the target virtual machine instruction can override (a) parameter types referenced by the target virtual machine instruction itself or (b) parameter types inferred by the runtime environment based on previously executed instructions.

[0049] One or more embodiments described in this specification and / or recited in the claims may not be included in this general summary section.

[0050] 2. System Architecture Overview

[0051] Figure 1 The illustrated example architecture in which the techniques described herein may be practiced is shown. The software and / or hardware components described with respect to the example architecture may be omitted or associated with a different set of functionality than that described herein. According to one or more embodiments, software and / or hardware components not described herein may be used within the environment. Therefore, the example environment should not be interpreted as limiting the scope of any claims.

[0052] like Figure 1As shown, computing architecture 100 includes source code files 101, which are compiled by compiler 102 into class files 103 representing a program to be executed. Class files 103 are then loaded and executed by execution platform 112, which includes a runtime environment 113, an operating system 111, and one or more application programming interfaces (APIs) 110 that enable communication between runtime environment 113 and the operating system. Runtime environment 112 includes virtual machine 104, which includes various components such as a memory manager 105 (which may include a garbage collector), a class file validator 106 that checks the validity of class files 103, a class loader 107 that locates and builds in-memory representations of classes, an interpreter 108 for executing virtual machine 104 code, and a just-in-time (JIT) compiler 109 for producing optimized machine-level code.

[0053] In an embodiment, computing architecture 100 includes source code files 101 that contain code that has been written in a particular programming language, such as Java, C, C++, C#, Ruby, Perl, or the like. Thus, source code files 101 adhere to a particular set of syntactic and / or semantic rules for the associated language. For example, code written in Java adheres to the Java Language Specification. However, because specifications are updated and revised over time, source code files 101 may be associated with a version number that indicates the revision of the specification that source code files 101 adhere to. The exact programming language used to write source code files 101 is generally not critical.

[0054] In various embodiments, the compiler 102 converts source code written according to specifications for the convenience of the programmer into machine or object code that can be directly executed by a specific machine environment, or an intermediate representation ("virtual machine code / instructions") such as bytecode that can be executed by a virtual machine 104 that can run on various specific machine environments. The virtual machine instructions can be executed by the virtual machine 104 in a more direct and efficient manner than the source code. Converting the source code to the virtual machine instructions includes mapping the source code functionality from the language to the virtual machine functionality that utilizes the underlying resources (such as data structures). Typically, the functionality presented in simple terms by the programmer via the source code is converted into more complex steps that map more directly to the instruction set supported by the underlying hardware on which the virtual machine 104 resides.

[0055] Generally speaking, programs are executed as compiled or interpreted programs. When a program is compiled, the code is globally transformed from a first language to a second language before execution. Since the code transformation is performed in advance, compiled code often has excellent runtime performance. In addition, since the transformation is performed globally before execution, techniques such as constant folding, dead code elimination, and inlining can be used to analyze and optimize the code. However, depending on the program being executed, the startup time may be very long. In addition, inserting new code will require the program to be offline, recompiled, and re-executed. For many dynamic languages ​​(such as Java) that are designed to allow code to be inserted during program execution, a purely compiled approach may be inappropriate. When a program is interpreted, the program's code is read line by line and converted into machine-level instructions while the program is executing. As a result, the program has a short startup time (can begin execution almost immediately), but runtime performance is reduced due to the immediate execution of the transformation. In addition, since each instruction is analyzed separately, many optimizations that rely on a more comprehensive analysis of the program cannot be performed.

[0056] In some embodiments, the virtual machine 104 includes an interpreter 108 and a JIT compiler 109 (or components that implement aspects of both), and uses a combination of interpretation and compilation techniques to execute the program. For example, the virtual machine 104 can initially start by interpreting the virtual machine instructions representing the program via the interpreter 108, while tracking statistical information related to program behavior, such as how often different code sections or code blocks are executed by the virtual machine 104. Once a code block exceeds a threshold (becomes "hot"), the virtual machine 104 calls the JIT compiler 109 to perform analysis on the block and generate optimized machine-level instructions, which replace the "hot" code block for future execution. Since programs often spend most of their time executing a small part of the entire code, only compiling the "hot" part of the program can provide performance similar to that of fully compiled code, but without the startup cost. In addition, although the optimization analysis is constrained to the "hot" block being replaced, there is still much greater optimization potential than converting each instruction separately. There are multiple variants in the above example, such as layered compilation.

[0057] To provide a clear example, source code file 101 has been illustrated as a "top-level" representation of a program to be executed by execution platform 111. Although computing architecture 100 depicts source code file 101 as a "top-level" program representation, in other embodiments, source code file 101 may be an intermediate representation received by a "higher-level" compiler that processes code files in different languages ​​into the language of source code file 101. Some examples in the following disclosure assume that source code file 101 conforms to a class-based, object-oriented programming language. However, this is not a requirement for utilizing the features described herein.

[0058] In an embodiment, compiler 102 receives source code file 101 as input and converts source code file 101 into class file 103 in a format expected by virtual machine 104. For example, in the context of the JVM, the Java Virtual Machine Specification defines a specific class file format that class files 103 are expected to follow. In some embodiments, class file 103 contains virtual machine instructions that have been converted from source code file 101. However, in other embodiments, class file 103 may also contain other structures, such as tables identifying constant values ​​and / or metadata associated with various structures (classes, fields, methods, etc.).

[0059] The following discussion assumes that each of the class files 103 represents a corresponding "class" defined in the source code file 101 (or dynamically generated by the compiler 102 / virtual machine 104). However, the foregoing assumption is not a strict requirement and will depend on the implementation of the virtual machine 104. Therefore, regardless of the exact format of the class files 103, the techniques described herein can still be performed. In some embodiments, the class files 103 are divided into one or more "libraries" or "packages", each of which includes a collection of classes that provide related functionality. For example, a library may contain one or more class files that implement input / output (I / O) operations, mathematical tools, cryptographic techniques, graphics utilities, etc. Further, some classes (or fields / methods within these classes) may include access restrictions that restrict their use to specific classes / libraries / packages or to classes with appropriate permissions.

[0060] 2.1 Example class file structure

[0061] Figure 2An example structure of a class file 200 in block diagram form according to an embodiment is illustrated. To provide a clear example, the remainder of this disclosure assumes that the class file 103 of the computing architecture 100 follows the structure of the example class file 200 described in this section. However, in an actual environment, the structure of the class file 200 will depend on the implementation of the virtual machine 104. Further, one or more features discussed herein may modify the structure of the class file 200 to, for example, add additional structure types. Therefore, the exact structure of the class file 200 is not critical to the techniques described herein. For the purposes of Section 2.1, a "class" or "current class" refers to the class represented by the class file 200.

[0062] exist Figure 2 In the embodiment, class file 200 includes constant table 201, field structure 208, class metadata 204 and method structure 209. In an embodiment, constant table 201 is a data structure that also serves as a symbol table of a class in addition to other functions. For example, constant table 201 can store data related to the various identifiers used in source code file 101, such as type, range, content and / or position. Constant table 201 has entries for value structure 202 (representing constant values ​​of types such as integer (int), long integer (long), double precision type (double), floating point type (float), byte type (byte), string (string), etc.), class information structure 203, name and type information structure 205, field reference structure 206 and method reference structure 207 derived from source code file 101 by compiler 102. In an embodiment, constant table 201 is implemented as an array that maps index i to structure j. However, the exact implementation of constant table 201 is not critical.

[0063] In some embodiments, entries of the constant table 201 include structures that index other entries of the constant table 201. For example, an entry for a value structure 202 in the value structures 202 that represents a string may hold a tag identifying the "type" of the value structure as a string and indexes to one or more other value structures 202 in the constant table 201 that store character (char) values, byte values, or integer values ​​representing the ASCII characters of the string.

[0064] In an embodiment, a field reference structure 206 of the constant table 201 holds: an index into one of the class information structures 203 in the constant table 201 that indicates the class that defines the field, and an index into one of the name and type information structures 205 in the constant table 201 that provide the name and descriptor of the field. A method reference structure 207 of the constant table 201 holds: an index into one of the class information structures 203 in the constant table 201 that indicates the class that defines the method, and an index into one of the name and type information structures 205 in the constant table 201 that provide the name and descriptor of the method. A class information structure 203 holds an index into one of the value structures 202 in the constant table 201 that holds the name of the associated class.

[0065] The name and type information structure 205 holds: an index to a value structure 202 pointing to the name of the storage field / method in the value structure 202 in the constant table 201, and an index to a value structure 202 pointing to the storage descriptor in the value structure 202 in the constant table 201.

[0066] In an embodiment, the class metadata 204 includes metadata of the class, such as (one or more) version numbers, the number of entries in the constant pool, the number of fields, the number of methods, access flags (whether the class is public, private, final, abstract, etc.), an index to a class information structure 203 in the class information structure 203 of the constant table 201 that identifies the current class, an index to a class information structure 203 in the class information structure 203 of the constant table 201 that identifies the superclass (if any), etc.

[0067] In an embodiment, field structures 208 represent a set of structures that identify various fields of a class. Field structures 208 store, for each field of the class, the field's accessor flags (whether the field is static, public, private, final, etc.), an index into a value structure 202 in constant table 201 that holds the name of the field, and an index into a value structure 202 in constant table 201 that holds the descriptor of the field.

[0068] In an embodiment, method structure 209 represents a set of structures that identify various methods of a class. Method structure 209 stores, for each method of the class, the method's accessor flags (e.g., whether the method is static, public, private, synchronized, etc.), an index into a value structure 202 in constant table 201 that holds the method's name, an index into a value structure 202 in constant table 201 that holds the method's descriptor, and the virtual machine instructions corresponding to the method's body as defined in source code file 101.

[0069] In an embodiment, a descriptor represents the type of a field or method. For example, a descriptor can be implemented as a string that follows a specific syntax. Although the exact syntax is not critical, several examples will be described below.

[0070] In the example where the descriptor represents the type of the field, the descriptor identifies the type of data held by the field. In an embodiment, a field can hold a primitive type, an object, or an array. When a field holds a primitive type, the descriptor is a string identifying the primitive type (e.g., "B" = byte, "C" = char, "D" = double, "F" = float, "I" = int, "J" = long int, etc.). When a field holds an object, the descriptor is a string identifying the class name of the object (e.g., "LClassName"). In this case, "L" indicates a reference, so "L ClassName" represents a reference to an object of class ClassName. When a field is an array, the descriptor identifies the type held by the array. For example, "[B" indicates an array of bytes, where "[" indicates an array and "B" indicates that the array holds a primitive byte type. However, since arrays can be nested, the descriptor of an array can also indicate nesting. For example, "[[L ClassName" indicates an array, where each index holds an array of objects of class ClassName. In some embodiments, ClassName is fully qualified and includes the simple name of the class and the path name of the class. For example, ClassName may indicate the location in the file system where the file is stored in a package, library, or managed class file 200 .

[0071] In the case of a method, the descriptor identifies the parameters of the method and the return type of the method. For example, a method descriptor can follow the general form "({ParameterDescriptor})ReturnDescriptor", where {ParameterDescriptor} is a list of field descriptors representing the parameters, and ReturnDescriptor is a field descriptor identifying the return type. For example, the string "V" can be used to represent a void return type. Thus, a method defined in source code file 101 as "Object m(int 1, double d, Thread t) {...}" matches the descriptor "(ID LThread)L Object".

[0072] In an embodiment, the virtual machine instructions held in method structure 209 include operations that reference entries of constant table 201. Using Java as an example, consider the following class:

[0073]

[0074] In the above example, a Java method add12and13 is defined in class A, which takes no parameters and returns an integer. The body of method add12and13 calls a static method addTwo of class B, which takes constant integer values ​​12 and 13 as parameters and returns a result. Therefore, in constant table 201, compiler 102 includes, in addition to other entries, a method reference structure corresponding to the call to method B.addTwo. In Java, a call to a method is compiled down to an invoke command in the bytecode of the JVM (invokestatic in this case, because addTwo is a static method of class B). The invoke command is provided with an index pointing to the method reference structure in constant table 201, which identifies the class "B" that defines addTwo, the name of addTwo "addTwo", and the descriptor "(II)I" of addTwo. For example, assuming that the aforementioned method reference is stored at index 4, the bytecode instruction can be represented as "invokestatic#4".

[0075] Because constant table 201 references classes, methods, and fields with structures that carry identification information symbolically rather than directly referencing memory locations, the entries of constant table 201 are called "symbolic references." One reason symbolic references are used for class files 103 is because in some embodiments, once a class is loaded into runtime environment 112, compiler 102 does not know how and where to store the class. As will be described in Section 2.3, after the referenced class (and associated structures) have been loaded into the runtime environment and assigned to specific memory locations, the runtime representation of the symbolic reference is ultimately resolved into an actual memory address by virtual machine 104.

[0076] 2.2 Example Virtual Machine Architecture

[0077] Figure 3 An example virtual machine memory layout 300 is illustrated in block diagram form according to an embodiment. To provide a clear example, the remaining discussion will assume that the virtual machine 104 follows Figure 3 . Furthermore, while components of virtual machine memory layout 300 may be referred to as memory "regions," there is no requirement that the memory regions be contiguous.

[0078] exist Figure 3 In the illustrated example, the virtual machine memory layout 300 is divided into a shared area 301 and a thread area 307. The shared area 301 represents an area in memory where structures shared between various threads executing on the virtual machine 104 are stored. The shared area 301 includes a heap 302 and a per-class area 303. In an embodiment, the heap 302 represents a runtime data area from which memory for class instances and arrays is allocated. In an embodiment, the per-class area 303 represents a memory area that stores data related to each class. In an embodiment, for each loaded class, the per-class area 303 includes a runtime constant pool 304 representing data from the constant table 201 of class, field, and method data 306 (for example, to hold static fields of the class), and includes method code 305 representing virtual machine instructions for methods of the class.

[0079] The thread area 307 represents a memory area that stores structures specific to each thread. Figure 3 , thread area 307 includes thread structures 308 and thread structures 311 that represent per-thread structures utilized by different threads. To provide a clear example, Figure 3 The thread region 307 depicted in FIG2 assumes that two threads are executing on the virtual machine 104. However, in a practical environment, the virtual machine 104 may execute any arbitrary number of threads, with the number of thread structures scaling accordingly.

[0080] In an embodiment, thread structure 308 includes a program counter 309 and a virtual machine stack 310. Similarly, thread structure 311 includes a program counter 312 and a virtual machine stack 313. In an embodiment, program counter 309 and program counter 312 store the current address of the virtual machine instruction being executed by their respective threads.

[0081] Therefore, as the thread executes instructions step by step, the program counter is updated to maintain an index pointing to the current instruction. In an embodiment, both virtual machine stack 310 and virtual machine stack 313 store frames for the respective threads of virtual machine stack 310 and virtual machine stack 313 that hold local variables and partial results and are also used for method calls and returns.

[0082] In an embodiment, a frame is a data structure used to store data and partial results, return method values, and perform dynamic linking. Each time a method is called, a new frame is created. When the method that generated the frame is completed, the frame is destroyed. Therefore, when a thread executes a method call, the virtual machine 104 generates a new frame and pushes the frame onto the virtual machine stack associated with the thread.

[0083] When the method call is completed, the virtual machine 104 passes the result of the method call back to the previous frame and pops the current frame from the stack. In an embodiment, for a given thread, a frame is active at any point. This active frame is called the current frame, so that the method that generates the current frame is called the current method, and the class to which the current method belongs is called the current class.

[0084] Figure 4 An example frame 400 is illustrated in block diagram form according to an embodiment. To provide a clear example, the remaining discussion will assume that the frames of virtual machine stack 310 and virtual machine stack 313 follow the structure of frame 400.

[0085] In an embodiment, frame 400 includes local variables 401, operand stack 402 and runtime constant pool reference table 403. In an embodiment, local variables 401 are represented as variable arrays, each variable holding a value, for example, a Boolean, byte, character, short, integer, floating point or reference type. Further, some value types (such as long integers or double precision types) can be represented by more than one entry in the array. Local variables 401 are used to pass parameters and store partial results on method calls. For example, when frame 400 is generated in response to a method call, parameters can be stored in predetermined locations within local variables 401, such as indexes 1-N corresponding to the 1st to Nth parameters in the call.

[0086] In an embodiment, when virtual machine 104 creates frame 400, operand stack 402 defaults to empty. Then, virtual machine 104 supplies instructions from the method code 305 of current method to load constants or values ​​from local variables 501 onto operand stack 502. Other instructions obtain operands from operand stack 402, operate on operands and push results back onto operand stack 402. In addition, operand stack 402 is used to prepare parameters that will be passed to method and receive method results. For example, the parameters of the called method can be pushed onto operand stack 402 before calling the method. Then, virtual machine 104 generates a new frame for method call, wherein the operands on the operand stack 402 of previous frame are popped out and loaded into the local variables 401 of new frame. When the called method terminates, new frame is popped out from virtual machine stack and return value is pushed onto operand stack 402 of previous frame.

[0087] In an embodiment, the runtime constant pool reference table 403 contains a reference to the runtime constant pool 304 of the current class. The runtime constant pool reference table 403 is used to support resolution. Resolution is the process of converting symbol references in the constant pool 304 into specific memory addresses, thereby loading classes as needed to resolve undefined symbols and converting variable accesses into appropriate offsets in storage structures associated with the runtime locations of these variables.

[0088] 2.3 Loading, Linking, and Initialization

[0089] In an embodiment, the virtual machine 104 dynamically loads, links, and initializes classes. Loading is the process of finding a class with a specific name and creating a representation of the class from its associated class file 200 within the memory of the runtime environment 112. For example, a runtime constant pool 304, method code 305, and field and method data 306 are created for each class within region 303 of the virtual machine memory layout 300. Linking is the process of taking the in-memory representation of the class and combining it with the runtime state of the virtual machine 104 so that the class's methods can be executed. Initialization is the process of executing a class constructor to set the starting state of the fields and method data 306 of the class and / or creating a class instance on the heap 302 for the initialized class.

[0090] The following are examples of loading, linking, and initialization techniques that may be implemented by the virtual machine 104. However, in many embodiments, these steps may be interleaved such that an initial class is loaded, and then a second class is loaded during linking to resolve symbolic references found in the first class, which in turn causes a third class to be loaded, and so on. Thus, the progress through the loading, linking, and initialization phases may vary from class to class. Further, some embodiments may delay ("lazy" execution) one or more functions of the loading, linking, and initialization process until the class is actually needed. For example, the resolution of a method reference may be delayed until the virtual machine instructions that call the method are executed. Thus, the exact timing of the execution steps may vary significantly between implementations for each class.

[0091] To begin the loading process, the virtual machine 104 starts by calling the class loader 107 that loads the initial class. The technology for specifying the initial class will vary depending on the embodiment. For example, a technology can enable the virtual machine 104 to accept a command line argument specifying the initial class when starting.

[0092] To load a class, the class loader 107 parses the class file 200 corresponding to the class and determines whether the class file 200 is well-formed (meets the syntactic expectations of the virtual machine 104). If it is not well-formed, the class loader 107 generates an error. For example, in Java, the error may be generated in the form of an exception, which is thrown to the exception handler for processing. Otherwise, the class loader 107 generates an in-memory representation of the class by allocating a runtime constant pool 304, method code 305, and field and method data 306 for the class in the per-class area 303.

[0093] In some embodiments, when class loader 107 loads a class, class loader 107 also recursively loads the superclasses of the loaded class. For example, virtual machine 104 can ensure that the superclasses of a particular class are loaded, linked, and / or initialized before continuing with the loading, linking, and initialization process of a particular class.

[0094] During linking, the virtual machine 104 validates the class, prepares the class, and performs resolution of symbolic references defined in the runtime constant pool 304 of the class.

[0095] To validate a class, the virtual machine 104 checks whether the class's in-memory representation is structurally correct. For example, the virtual machine 104 may check that each class, except for the general class Object, has a superclass; that final classes have no subclasses and that final methods are not overridden; that constant pool entries are consistent with one another; that the current class has the correct access permissions to classes / fields / structures referenced in the constant pool 304; and that the virtual machine 104 code for a method will not cause unexpected behavior (e.g., ensuring that a jump instruction will not send the virtual machine 104 beyond the end scope of the method). The exact checks performed during validation depend on the implementation of the virtual machine 104. In some cases, validation may result in the loading of additional classes, but does not necessarily require that these classes be linked before proceeding. For example, suppose class A contains a reference to a static field of class B. During validation, the virtual machine 104 may check class B to ensure that the referenced static field actually exists. This may result in class B being loaded, but does not necessarily result in class B being linked or initialized. However, in some embodiments, certain validation checks may be delayed until a later stage, such as during the resolution of symbolic references. For example, some embodiments may delay checking access permissions on symbolic references until those references are resolved.

[0096] To prepare the class, the virtual machine 104 initializes the static fields located within the class and the method data 306 of the class to default values. In some cases, setting the static fields to default values ​​may be different from running the class's constructor. For example, the verification process may clear the static fields to zero or set them to the values ​​that the constructor expects these fields to have during initialization.

[0097] During parsing, the virtual machine 104 dynamically determines the specific memory address from the symbolic reference included in the runtime constant pool 304 of the class. To resolve the symbolic reference, the virtual machine 104 uses the class loader 107 to load the class identified in the symbolic reference (if not already loaded). Once the class is loaded, the virtual machine 104 knows the memory location within the area 303 of each class of the referenced class and its fields / methods. The virtual machine 104 then replaces the symbolic reference with a reference to the specific memory location of the referenced class, field, or method. In an embodiment, the virtual machine 104 caches the resolution and will reuse the resolution when the virtual machine 104 encounters the same class / name / descriptor when processing another class. For example, in some cases, class A and class B may call the same method of class C. Therefore, when performing parsing on class A, the result can be cached and reused during parsing the same symbolic reference in class B to reduce overhead.

[0098] In some embodiments, the step of resolving symbol references during linking is optional. For example, an embodiment may perform symbol resolution in a "lazy" manner, thereby delaying the step of resolution until a virtual machine instruction requiring the referenced class / method / field is executed.

[0099] During initialization, the virtual machine 104 executes the constructor of the class to set the starting state of the class. For example, initialization can initialize the field and method data 306 of the class and generate / initialize any class instances on the heap 302 created by the constructor. For example, the class file 200 for the class can specify a specific method as the constructor for setting the starting state. Therefore, during initialization, the virtual machine 104 executes the instructions of the constructor.

[0100] In some embodiments, the virtual machine 104 performs resolution on field and method references by initially checking whether the field / method is defined in the referenced class. In addition, the virtual machine 104 recursively searches the superclasses of the referenced class for the referenced field / method until the field / method is located or the top-level superclass is reached, in which case an error is generated.

[0101] 3. Extended virtual machine instruction set architecture

[0102] As described above, the compiler can convert source code into bytecode including virtual machine instructions that can be executed by the virtual machine. One or more embodiments are applicable to specific virtual machine instructions that can operate on different types of parameters. Examples of virtual machine instructions supported by the Java virtual machine that can operate on different types of parameters include, but are not limited to: aload, astore, areturn, aaload, aastore, anewarray, multianewarray, and checkcast.

[0103] Different types of parameters include primitive type parameters and reference type parameters. Primitive types include byte, short integer, integer, long integer, float, double, character, string, object, Boolean, and return address. Reference types include class types, array types, and interface types.

[0104] The parameter type may correspond to or include semantics associated with a virtual machine instruction. In one example, the parameter type may be used in conjunction with a "value type." A value type may represent a user-defined aggregate type without the characteristics of supporting memory-efficient and locality-efficient programming idioms that may be exposed in the language of the source code file and the instruction set of the virtual machine without sacrificing encapsulation.

[0105] In an embodiment, a value type is a heterogeneous aggregate that can contain primitive types, reference types, or even other value types. In some embodiments, such as in Java, many definitions and encapsulation mechanisms for classes can be used to easily and safely construct data structures based on new value type constructs. For example, a value type can be viewed as a specially marked and restricted form of class definition. From a semantic point of view, a value type functions as a new primitive type for virtual machine users. A detailed description of "value types" is included in Appendix C accompanying this document.

[0106] 3.1 Reference to parameter types of virtual machine instructions

[0107] Figure 5 An example of a bytecode (e.g., bytecode 502) including any number of virtual machine instructions is shown. Each virtual machine instruction includes any number of parameters. For clarity, Figure 5 Virtual machine instruction 506 and parameter 508 are illustrated in and described below. Information 504 may correspond to another virtual machine instruction associated with virtual machine instruction 506, as described in detail below.

[0108] In an embodiment, the compiler generates and stores information (e.g., information 504) that references parameter types 510 of parameters 508 of virtual machine instructions 506. The compiler stores information 504 within the same set of bytecodes 502 as virtual machine instructions 506. The compiler stores information 504 external to virtual machine instructions 506 and in association with virtual machine instructions 506. The virtual machine processes virtual machine instructions 506 based on parameter types 510, as described below with reference to Figure 6 Parameter 510 covers other parameter types (e.g., parameter type 512) that are referenced by the virtual machine instruction 506 itself or that can be inferred by the virtual machine based on previously executed virtual machine instructions (see below). Figure 6 Detailed description).

[0109] In an embodiment, the association between information 504 and virtual machine instructions 506 can be indicated by a compiler (and subsequently identified by the virtual machine) based at least on the proximity and / or location of information 504 relative to virtual machine instruction 506. As an example, information stored outside of and immediately before virtual machine instruction 506 can be determined to be associated with virtual machine instruction 506. In another embodiment, information stored outside of and immediately after virtual machine instruction 506 can be determined to be associated with virtual machine instruction 506.

[0110] In an embodiment, information 504 references parameter type 510 by referencing a variable corresponding to parameter type 510. The value of the variable (i.e., parameter type 510) may be stored at a specific location in a constant table. Alternatively or additionally, a specific location in a constant table may be designated for storing the value of the variable. When information 504 (a) referencing the variable is generated and (b) stored as associated with and external to virtual machine instructions 506, the value of the variable may or may not be known.

[0111] In an embodiment, information 504 references parameter type 510 by referencing a variable corresponding to a method handle (see class MethodHandle in the Java API). A method handle is a typed, direct, executable reference to the underlying method that returns parameter type 510.

[0112] In the example, information 504 includes a metadata reference to a constant pool that indicates a parameter type 510 of a parameter 508 of a virtual machine instruction 506. The metadata reference can be, for example, a 16-bit reference to a constant pool for a class corresponding to the virtual machine instruction 506. The referenced constant pool entry can be any type of entry that describes a type.

[0113] In an embodiment, information 504 is implemented as a second virtual machine instruction stored adjacent to (e.g., immediately before) virtual machine instruction 506. The second virtual machine instruction includes a parameter of parameter type 510 that references parameter 508 of virtual machine instruction 506. The parameter of the second virtual machine instruction can reference a variable that corresponds to parameter type 510 of parameter 508 of virtual machine instruction 506. The parameter of the second virtual machine instruction can include metadata reference to a constant pool that indicates parameter type 510 of parameter 508 of virtual machine instruction 506.

[0114] In an embodiment, a special keyword can be used to signal a reference to parameter type 510 of parameter 508 of virtual machine instruction 506. As an example, information 504 corresponds to a second virtual machine instruction including the special keyword "typed." This special keyword signals to the runtime environment that the second virtual machine includes information referencing parameter type 510 of parameter 508 of virtual machine instruction 506.

[0115] As an example, the virtual machine instruction 506 (referred to as an "opcode") is preceded by type information in one of the following example formats;

[0116]

[0117] In the above example format, "typed" is a signal to inform <opcode>The keyword of the type information that follows. In format 1, <opcode>The arguments to an opcode (that is, the parameters on which the opcode operates) are stored as local variables. <opcode>Examples of (i.e., instructions used with format 1) include, but are not limited to: aload_0,1,2,3, astore_0,1,2,3, dup, dup_x1, dup_x2, dup2, dup2_x1, dup2_x2, areturn, aalaod, aastore, and cmp_eq. In format 2, <opcode>The parameters of the opcode (that is, the parameters on which the opcode operates) are in <opcode>after. <opcode>Examples of (i.e., instructions used with format 2) include, but are not limited to: aload, astore, anewarray, multinewarray, and checkcast.

[0118] 3.2 Processing virtual machine instructions based on external reference parameter types

[0119] Figure 6 A set of example operations for processing a virtual machine instruction with at least one parameter according to one or more embodiments is illustrated. For example, a virtual machine instruction can operate on a parameter stored in a data structure (e.g., a stack maintained by the virtual machine). For example, the result of executing a virtual machine instruction is stored in the stack. The next executed virtual machine instruction operates on the parameter corresponding to the last value stored in the stack (the result from the previously executed virtual machine instruction). The virtual machine instruction can specify the parameter after the opcode.

[0120] The following references may be rearranged, omitted, or modified Figure 6 As an alternative to or in addition to the operations described, additional operations not described below may be performed. Therefore, the operations described below should not be interpreted as limiting the scope of any claims described herein.

[0121] One or more embodiments include determining whether a virtual machine instruction that operates on at least one parameter is stored in association with external information referencing a corresponding parameter type (operation 602).

[0122] A virtual machine processing a virtual machine instruction may be configured to detect information external to the virtual machine instruction that references parameter types of parameters of the virtual machine instruction. As described above, such information may be stored within the same set of bytecodes as the virtual machine instruction. Furthermore, such information may be stored in association with the virtual machine instruction.

[0123] In an embodiment, the virtual machine detects information referencing parameter types based on information that matches a defined set of standards. The standard may require, for example, (a) the location of the information relative to the virtual machine instruction or (b) a specific keyword. As an example, the compiler stores information about the parameter type of a parameter that references a first virtual machine instruction in a second virtual machine instruction that (a) immediately precedes the first virtual machine instruction and (b) includes the specific keyword "typed". The virtual machine (or runtime environment) is configured to determine that the virtual machine instruction including "typed" corresponds to information about the parameter type of the parameter that references the parameter immediately following the virtual machine instruction. In other examples, the compiler may include information about the parameter type of the parameter that references the virtual machine instruction in other formats recognized by the virtual machine.

[0124] If external information referencing parameter types of parameters of a virtual machine instruction is detected, the virtual machine processes the virtual machine instruction based on the parameter types referenced by the external information (operation 604). This virtual machine instruction (to be processed based on the parameter types referenced by the external information) can be a complete and fully executable instruction independent of (and even in the absence of) the parameter types referenced by the external information. The information stored external to the first virtual machine instruction and stored in association with the first virtual machine instruction refines, tailors, or specifies the operation of the first virtual machine instruction for a more specific purpose as indicated by the external information. In the absence of external information, the first virtual machine instruction can still be executed using a set of types suitable for various purposes, including specific purposes.

[0125] In order to process a virtual machine instruction based on a parameter type referenced by external information, the parameter type must first be determined. The information may reference a memory location and / or variable that is accessed to determine the corresponding parameter type. The information may reference a MethodHandle associated with a method that is executed to return the parameter type.

[0126] Processing a virtual machine instruction based on a parameter type referenced by external information includes performing an action selected based on the parameter type. As an example, the number of bytes to be processed from a data structure (e.g., a stack) can be selected based on the parameter type referenced by external information. The bytes can be used for data movement operations, data comparison operations, or data retrieval operations. As another example, the parameter type referenced by external information can be used for type conversion, generic method calls, or any other type of operation.

[0127] Parameter types referenced by external information override other parameter types that can be identified by the virtual machine. Parameter types referenced by information stored external to and associated with the virtual machine instruction override parameter types referenced by the virtual machine instruction itself. Parameter types referenced by information stored external to and associated with the virtual machine instruction override other parameter types that can be inferred by the virtual machine based on previously executed instructions. Parameter types referenced by information stored external to and associated with the virtual machine instruction override parameter types stored along with parameter values ​​within a data structure maintained by the virtual machine (e.g., a stack).

[0128] There are a number of different techniques that can be implemented for overriding parameter types. In one example, Figure 6 As shown, other parameter types that can be determined by the virtual machine are never identified. Specifically, when information is detected that (a) is stored outside the virtual machine instruction and stored in association with the virtual machine instruction and (b) references the parameter type, operations 608-610 related to other parameter types are omitted.

[0129] In other examples, other parameter types are first determined (e.g., inferred by the virtual machine based on previously executed instructions or referenced by the target virtual machine instruction itself). Thereafter, if information is detected that is (a) stored externally to and associated with the virtual machine instruction and (b) references the parameter type, the obsolete parameter type is discarded / explicitly overwritten.

[0130] Return to Figure 6 If, in operation 602, no external information referencing a parameter type is detected, the virtual machine may process the virtual machine instruction based on any parameter type inferred by the virtual machine based on a previously executed instruction or referenced by the target virtual machine instruction itself (operations 608-610). As an example, a previously executed virtual machine instruction adds two integers and stores the value on a stack. The next instruction executed operates on the last stored value as a parameter. The last value stored on the stack is known to be an integer because it is generated by adding two integers. Therefore, the parameter type integer can be inferred by the virtual machine. In addition, the parameter type integer can be stored on the stack in association with the last stored value.

[0131] If parameter type information is not identified for the virtual machine instruction, an error may be generated or a base type may be used as the parameter type for processing the virtual machine instruction (operation 612). Whether an error is generated or a base type is used may depend on the virtual machine instruction, the configuration of the virtual machine, or any other factors. For example, an "object" type may be used as a parameter type for processing a virtual machine instruction having parameters without any associated parameter types.

[0132] 3.3 Example use of referenced parameter types

[0133] For different virtual machine instructions, information about the type of the parameter(s) of the referenced virtual machine instruction may or may not be included. Embodiments herein relate to generating and using bytecodes having one or both of the following:

[0134] (a) A virtual machine instruction is stored in association with information (external to the virtual machine instruction) that references a parameter type of a parameter of the virtual machine instruction (see operation 604 ).

[0135] (b) A stored virtual machine instruction having no information (external to the virtual machine instruction) referencing a parameter type of a parameter of the virtual machine instruction (see operations 608 - 612 ).

[0136] In an embodiment, the decision to include information referencing the parameter type of any virtual machine instruction may depend on any number of factors, including, but not limited to, the actual type of the parameter to the virtual machine instruction, whether the virtual machine instruction requires increased versatility (e.g., to account for platform evolution), and whether (e.g., for new types) specific semantics need to be signaled / whether specific semantics are applicable.

[0137] Using information about the parameter types of referenced virtual machine instructions can help avoid the need for additional value type information. Using information about the types of previously referenced instruction parameters can provide an enhanced method for communicating parameter types with the execution engine.

[0138] Generic Type Specialization: In one example, which should not be construed as limiting the scope of any claim, bytecode for generic classes and methods is generated so that information about reference parameter types is used when virtual machine instructions operate on values ​​of the generic type. Specializing the generic class or method includes specializing metadata associated with the parameter types of the virtual machine instruction's parameters to include the correct types. In this manner, virtual machine instructions associated with the generic type specialization are coercively typed.

[0139] Adding Types: In an embodiment, reference parameter types allow for extending the semantics of instructions. Parameter types provide context to a particular virtual machine instruction and can be used to map a particular set of semantics to all sets of semantics applicable to a particular virtual machine instruction. New semantics for value types (whose elements can consume more than one machine word than is typically found in Java types) can be represented by reference parameter types to instructions that process value type elements in the constant pool.

[0140] Dynamic language implementations: Dynamic language implementations that target a VM platform ISA by compiling source language functions can use argument types to generate bytecodes that are highly specific about the types that occur.

[0141] As described above, one or more embodiments are applicable to identifying types as value types. In one example, value types must be supported by a generic type system. As described above, a flexible generic specialization method may be helpful. Specializing a generic type includes patching a constant pool entry referenced by information preceding a virtual machine instruction.

[0142] In one example, inlining is an optimization that replaces a method call by replacing the call with the body of the called method. As a result, the virtual machine is able to omit jump instructions, which are often quite expensive. Furthermore, inlining can be performed recursively ("deep inlining"), so if method A calls method B, which in turn calls method C, the contents of both method B and method C can be inlined into method A. However, when the method call is potentially polymorphic (such as the JVMinvokevirtual instruction), the virtual machine may not know exactly which implementation of the method will be called during runtime and therefore should be inlined.

[0143] For example, consider an abstract class Feline with a subclass HouseCat and another subclass Lion. HouseCat implements the method speak by printing "meow", and Lion implements the method speak by printing "roar". Suppose method C takes a parameter object of type Feline and calls the speak method of that object. Method C is called by both method A and method B, where method A passes a parameter of type HouseCat to method C and method B passes a parameter of type Lion to method C. In this example, if the virtual machine attempts to perform a deep inline of method C into method A, the type information of the speak call in method C will indicate that both types Lion and HouseCat have already been considered as receivers at that point in the program (assuming that both method A and method B have been executed at least once). Therefore, the virtual machine will not be able to resolve which implementation of speak to inline into method C and will ultimately be inlined into method A.

[0144] To address these issues, an embodiment relies on the types of the arguments to the call. The virtual machine accesses the parameter types (referenced by information prior to the call) of the arguments to the call from method A to method C that indicate that the type of the passed argument is HouseCat. As a result, instead of optimizations based on the assumption that the argument has the declared type Feline and that the receiver cannot be resolved due to a tainted profile, the information related to the type of the passed argument allows the virtual machine to determine that the receiver of the speak call is of the more specific type HouseCat when the call is made from method A. Thus, the argument types flow from the caller to the callee based on the information referencing the argument types. Once the more specific type has been resolved, the virtual machine is able to determine which implementation of speak to inline during the compilation and optimization process.

[0145] 4. Other; Extension

[0146] Embodiments are directed to a system having one or more devices comprising a hardware processor and configured to perform any of the operations described herein and / or in any of the following claims.

[0147] In an embodiment, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or in any claims.

[0148] Any combination of the features and functions described herein may be used in accordance with one or more embodiments. In the foregoing description, various embodiments have been described with reference to numerous specific details that may vary from one embodiment to another. The description and drawings should therefore be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what the applicants intend as the scope of the invention, is the literal and equivalent scope of the claims issued from this application in their specific form, including any subsequent corrections.

[0149] 5. Hardware Overview

[0150] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. Special-purpose computing devices can be hard-wired to perform technology, or can include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform technology, or can include one or more general-purpose hardware processors that are programmed to perform technology according to program instructions in firmware, memory, other storage devices, or a combination thereof. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, or FPGAs with customized programming to implement technology. Special-purpose computing devices can be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that combine hard-wiring and / or program logic to implement technology.

[0151] For example, Figure 7 7 is a block diagram illustrating a computer system 700 upon which embodiments of the present invention may be implemented. Computer system 700 includes a bus 702 or other communication mechanism for communicating information, and a hardware processor 704 coupled with bus 702 for processing information. Hardware processor 704 may be, for example, a general-purpose microprocessor.

[0152] Computer system 700 also includes a main memory 706, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 702 for storing information and instructions to be executed by processor 704. Main memory 706 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 704. These instructions, when stored in a non-transitory storage medium accessible to processor 704, make computer system 700 a special-purpose machine customized to perform the operations specified in the instructions.

[0153] Computer system 700 further includes a read only memory (ROM) 708 or other static storage device coupled to bus 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic or optical disk, is provided and coupled to bus 702 for storing information and instructions.

[0154] The computer system 700 may be coupled via bus 702 to a display 712, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 714, including alphanumeric and other keys, is coupled to bus 702 for communicating information and command selections to processor 704. Another type of user input device is a cursor control 716, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to processor 704 and for controlling cursor movement on display 712. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allow the device to specify a position in a plane.

[0155] The computer system 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, enables or programs the computer system 700 to function as a special-purpose machine. According to one embodiment, the techniques herein are performed by the computer system 700 in response to the processor 704 executing one or more sequences of one or more instructions contained in the main memory 706. These instructions may be read into the main memory 706 from another storage medium, such as the storage device 710. Execution of the sequences of instructions contained in the main memory 706 causes the processor 704 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0156] As used herein, the term "storage medium" refers to any non-transient medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cassette.

[0157] Storage media are distinct from, but may be used in conjunction with, transmission media. Transmission media participate in the transmission of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 702. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0158] Carrying one or more sequences of one or more instructions to the processor 704 for execution may involve various forms of media. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 700 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on the bus 702. The bus 702 carries the data to the main memory 706, from which the processor 704 retrieves and executes the instructions. The instructions received by the main memory 706 may optionally be stored on the storage device 710 before or after execution by the processor 704.

[0159] Computer system 700 also includes a communication interface 718 coupled to bus 702. Communication interface 718 provides two-way data communication coupled to network link 720, wherein network link 720 is connected to local network 722. For example, communication interface 718 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or modem that provides data communication connection to a corresponding type of telephone line. As another example, communication interface 718 can be a LAN card that provides data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 718 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0160] The network link 720 typically provides data communication to other data devices through one or more networks. For example, the network link 720 can provide a connection to a host computer 724 or to data equipment operated by an Internet Service Provider (ISP) 726 through a local network 722. The ISP 726, in turn, provides data communication services through the worldwide packet data communication network now commonly referred to as the "Internet" 728. Both the local network 722 and the Internet 728 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 720 and through the communication interface 718 are example forms of transmission media that carry digital data to and from the computer system 700.

[0161] Computer system 700 can send messages and receive data, including program code, through the network(s), network link 720, and communication interface 718. In the Internet example, server 730 can transmit requested code for an application program through Internet 728, ISP 726, local network 722, and communication interface 718.

[0162] The received code may be executed by processor 704 as it is received, and / or stored in storage device 710 or other non-volatile storage for later execution.

[0163] In the foregoing description, embodiments of the present invention have been described with reference to numerous specific details that may vary from embodiment to embodiment. The description and drawings should therefore be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what applicants intend as the scope of the invention, is the literal and equivalent scope of the claims issued from this application in their specific form, including any subsequent amendments.< / opcode> < / opcode> < / opcode> < / opcode> < / opcode> < / opcode>

Claims

1. A non-transitory computer-readable medium comprising instructions that, when executed by one or more hardware processors, cause execution of the steps comprising: executing, by a virtual machine within a set of compiled code, a first set of one or more virtual machine instructions, the first set of one or more virtual machine instructions (a) including or referencing type information for one or more parameters of a second virtual machine instruction, and (b) including a keyword that signals to the virtual machine that the type information is included or referenced for the one or more parameters of the second virtual machine instruction, wherein the second virtual machine instruction operates on and at least one of the one or more parameters associated with the type information is stored by at least one local variable; In response to executing the first set of virtual machine instructions by the virtual machine, determining the type information of the one or more parameters of the second virtual machine instruction; Second virtual machine instructions are executed by the virtual machine within the set of compiled codes based on the type information determined in response to executing the first set of virtual machine instructions, the second virtual machine instructions including specific operations using at least the one or more parameters. 2 . The non-transitory computer-readable medium of claim 1 , wherein at least one virtual machine instruction in the first set of virtual machine instructions is adjacent to a second virtual machine instruction. 3 . The non-transitory computer-readable medium of claim 1 , wherein at least one virtual machine instruction in the first set of virtual machine instructions precedes the second virtual machine instruction. 4 . The non-transitory computer-readable medium of claim 1 , wherein the type information indicates one or more variables in a constant pool that reference one or more parameter types. 5 . The non-transitory computer-readable medium of claim 1 , wherein at least one parameter type referenced by the second virtual machine instruction is overridden by the type information determined in response to executing the first set of virtual machine instructions.

6. The non-transitory computer-readable medium of claim 1, wherein the second virtual machine instruction comprises a data move operation, and wherein a number of bytes moved in the data move operation is determined based at least on the type information.

7. The non-transitory computer-readable medium of claim 1 , wherein executing the second set of virtual machine instructions causes the specific operation to be performed on a specific number of bytes in the data structure, wherein the specific number is determined based at least on the type information determined in response to executing the first set of virtual machine instructions.

8. The non-transitory computer-readable medium of claim 1, wherein the type information references a generic type.

9. The non-transitory computer-readable medium of claim 1, wherein the type information is not statically known during a code compilation process that generates the set of compiled code.

10. The non-transitory computer-readable medium of claim 1, wherein the keyword signals to a virtual machine that the type information follows a second virtual machine instruction.

11. The non-transitory computer readable medium of claim 1, wherein the type information overrides a parameter type determined from a previously executed instruction.

12. A method for extending a virtual machine instruction set architecture, the method comprising: executing, by a virtual machine within a set of compiled code, a first set of one or more virtual machine instructions, the first set of one or more virtual machine instructions (a) including or referencing type information for one or more parameters of a second virtual machine instruction, and (b) including a keyword that signals to the virtual machine that the type information is included or referenced for the one or more parameters of the second virtual machine instruction, wherein the second virtual machine instruction operates on and at least one of the one or more parameters associated with the type information is stored by at least one local variable; In response to executing the first set of virtual machine instructions by the virtual machine, determining the type information of the one or more parameters of the second virtual machine instruction; executing, by the virtual machine, second virtual machine instructions within the set of compiled code based on the type information determined in response to executing the first set of virtual machine instructions, the second virtual machine instructions including a specific operation using at least the one or more parameters; The method is performed by at least one device including a hardware processor.

13. The method of claim 12, wherein the first group of virtual machine instructions are adjacent to the second group of virtual machine instructions. The method of claim 12 , wherein the first set of virtual machine instructions precedes the second set of virtual machine instructions.

15. The method of claim 12, wherein the type information indicates one or more variables in a constant pool that reference one or more parameter types.

16. A system for extending a virtual machine instruction set architecture, the system comprising: at least one device comprising a hardware processor; and The system is configured to perform operations including: executing, by a virtual machine within a set of compiled code, a first set of one or more virtual machine instructions, the first set of one or more virtual machine instructions (a) including or referencing type information for one or more parameters of a second virtual machine instruction, and (b) including a keyword that signals to the virtual machine that the type information is included or referenced for the one or more parameters of the second virtual machine instruction, wherein the second virtual machine instruction operates on and at least one of the one or more parameters associated with the type information is stored by at least one local variable; In response to executing the first set of virtual machine instructions by the virtual machine, determining the type information of the one or more parameters of the second virtual machine instruction; Second virtual machine instructions are executed by the virtual machine within the set of compiled codes based on the type information determined in response to executing the first set of virtual machine instructions, the second virtual machine instructions including specific operations using at least the one or more parameters.

17. The system of claim 16, wherein the first set of virtual machine instructions are adjacent to the second set of virtual machine instructions.

18. The system of claim 16, wherein the first set of virtual machine instructions precedes the second set of virtual machine instructions.

Images