Abstract: Garbage collection or other computational work accesses memory which is located outside processor registers. Some embodiments specify at least some of the memory accesses and separate them from other computations, and utilize a memory access state machine to control the execution of both kinds of computation. Code that employs memory access results is placed in a run routine which is divided between respective states of the state machine. The specified memory accesses are invoked from a state code, and overlap other computation. A prefetch buffer may be dynamically sized based on the availability of space in the prefetch buffer. Code for shared work, such as address relocation code, may be placed in its own state structure. Candidate code for possible separation into a specified memory access routine may be automatically recognized.

Abstract: Computational costs are reduced for garbage collection or other computational work that accesses memory which is located outside processor registers. Cost reduction is accomplished by specifying at least some of the memory accesses and separating them from other computations, and by utilizing a memory access cost management state machine to control the execution of both kinds of computation. Code that employs memory access results is placed in a run routine which is divided between respective states of the state machine. The specified memory accesses are invoked from a state code, and overlap other computation to reduce overall execution time. A prefetch buffer may be dynamically sized based on the availability of space in the prefetch buffer. Code for shared work, such as address relocation code, may be placed in its own state structure. Candidate code for possible separation into a specified memory access routine may be automatically recognized.

Abstract: An arena-based memory management system is disclosed. In response to a call to reclaim memory storing a group of objects allocated in an arena, an object not in use of the group of objects allocated in the arena is collected. A live object of the plurality of objects is copied from the arena to a heap.

Abstract: An arena-based memory management system is disclosed. In response to a call to reclaim memory storing a group of objects allocated in an arena, an object not in use of the group of objects allocated in the arena is collected. A live object of the plurality of objects is copied from the arena to a heap.

Abstract: A precompiled form of information derived from CIL metadata is created in a compact type layout (CTL) format. Information in CTL format for each data type in a program can be represented as a contiguous byte stream. Information that is irrelevant to decisions concerning layout of a data type in memory can be suppressed. Information that is irrelevant to creation of virtual machine data structures can be suppressed. The information in CTL format may reference types, methods, and fields by CIL metadata token. Virtual override information such as, for example, a logical virtual table layout, can be pre-computed. Interface implementation information can be pre-computed. A decoder can generate data structures used in generation of an executable from the CTL formatted data.

Abstract: Compatibility can be maintained when program code and pre-computed data associated with the program code are distributed in separate modules by using a data structure of key/value pairs comprising a dictionary. The dictionary can include a fixed part, a floating part and a version number. The version number in the dictionary can be used to determine if a dictionary for the program is current or outdated by comparing the dictionary version number and the version number associated with a dictionary layout in the current shared library. The dictionary can be rebuilt dynamically if the version number of the dictionary does not match the version number of the dictionary layout in the current shared library. The version number of the dictionary can be updated to the version associated with the layout version and the version pointer in the dictionary can be updated to point to the updated version number.

Abstract: Compatibility can be maintained when program code and pre-computed data associated with the program code are distributed in separate modules by using a data structure of key/value pairs comprising a dictionary. The dictionary can include a fixed part, a floating part and a version number. The version number in the dictionary can be used to determine if a dictionary for the program is current or outdated by comparing the dictionary version number and the version number associated with a dictionary layout in the current shared library. The dictionary can be rebuilt dynamically if the version number of the dictionary does not match the version number of the dictionary layout in the current shared library. The version number of the dictionary can be updated to the version associated with the layout version and the version pointer in the dictionary can be updated to point to the updated version number.

Abstract: A precompiled form of information derived from CIL metadata is created in a compact type layout (CTL) format. Information in CTL format for each data type in a program can be represented as a contiguous byte stream. Information that is irrelevant to decisions concerning layout of a data type in memory can be suppressed. Information that is irrelevant to creation of virtual machine data structures can be suppressed. The information in CTL format may reference types, methods, and fields by CIL metadata token. Virtual override information such as, for example, a logical virtual table layout, can be pre-computed. Interface implementation information can be pre-computed. A decoder can generate data structures used in generation of an executable from the CTL formatted data.

Abstract: A precompiled form of information derived from CIL metadata is created in a compact type layout (CTL) format. Information in CTL format for each data type in a program can be represented as a contiguous byte stream. Information that is irrelevant to decisions concerning layout of a data type in memory can be suppressed. information that is irrelevant to creation of virtual machine data structures can be suppressed. The information in CTL format may reference types, methods, and fields by CIL metadata token. Virtual override information such as, for example, a logical virtual table layout, can be pre-computed. Interface implementation information can be pre-computed. A decoder can generate data structures used in generation of an executable from the CTL formatted data.

Abstract: A precompiled form of information derived from CIL metadata is created in a compact type layout (CTL) format. Information in CTL format for each data type in a program can be represented as a contiguous byte stream. Information that is irrelevant to decisions concerning layout of a data type in memory can be suppressed. Information that is irrelevant to creation of virtual machine data structures can be suppressed. The information in CTL format may reference types, methods, and fields by CIL metadata token. Virtual override information such as, for example, a logical virtual table layout, can be pre-computed. Interface implementation information can be pre-computed. A decoder can generate data structures used in generation of an executable from the CTL formatted data.

Abstract: In a change-resilient intermediate language code, registers have been allocated but symbolic references and pseudo instructions still use unbound items. Pseudo instructions having a specific location within generated intermediate language code request insertion of machine instruction(s) at the location to perform specified operations. Specified operations may include, for example, operations to perform or facilitate garbage collection, memory allocation, exception handling, various kinds of method calls and execution engine service calls, managed object field access, heap management, generic code, static variable storage access, address mode modification, and/or symbolic reference to types. A binder may transform the intermediate language code into executable code. Little or no register allocation is needed during binding, but unbound items such as offsets, sizes, slots, and the like are determined and specified to produce executable code.

Abstract: Management of changes involving base classes is facilitated. An intermediate language code has execution-ready register allocation but unbound object field layout and/or virtual method slot assignment, thereby providing resilience. A symbolic reference rather than a direct offset can identify a field, and intermediate language code can be field order independent. Other symbolic references may also be used. Intermediate language code pseudo instructions can express items such as a field access, a method call, a virtual method call, part or all of a method prolog, part or all of a method epilog. A binder binds the intermediate language code to produce executable code. Thus, one may avoid recompilation otherwise required when a base class is revised by adding a field, removing a private field, rearranging field order, adding a virtual method, or rearranging virtual method order.

Abstract: In a change-resilient intermediate language code, registers have been allocated but symbolic references and pseudo instructions still use unbound items. Pseudo instructions having a specific location within generated intermediate language code request insertion of machine instruction(s) at the location to perform specified operations. Specified operations may include, for example, operations to perform or facilitate garbage collection, memory allocation, exception handling, various kinds of method calls and execution engine service calls, managed object field access, heap management, generic code, static variable storage access, address mode modification, and/or symbolic reference to types. A binder may transform the intermediate language code into executable code. Little or no register allocation is needed during binding, but unbound items such as offsets, sizes, slots, and the like are determined and specified to produce executable code.

Abstract: Management of changes involving base classes is facilitated. An intermediate language code has execution-ready register allocation but unbound object field layout and/or virtual method slot assignment, thereby providing resilience. A symbolic reference rather than a direct offset can identify a field, and intermediate language code can be field order independent. Other symbolic references may also be used. Intermediate language code pseudo instructions can express items such as a field access, a method call, a virtual method call, part or all of a method prolog, part or all of a method epilog. A binder binds the intermediate language code to produce executable code. Thus, one may avoid recompilation otherwise required when a base class is revised by adding a field, removing a private field, rearranging field order, adding a virtual method, or rearranging virtual method order.

Abstract: A visual development system having an interface which assists a user with input of source code expressions and statements during creation of a computer program is described. The interface includes an Integrated Development Environment (IDE) interface having a code editor with “Code Completion” and “Code Parameter” features for displaying context sensitive pop-up windows within a source code file. Code Completion is implemented at the user interface level by displaying a Code Completion dialog box after the user enters a record or class name followed by a period. For a class, the dialog lists the properties, methods and events appropriate to the class. For a record or structure, the dialog lists the data members of the record. To complete entry of the expression, the user need only select an item from the dialog list, whereupon the system automatically enters the selected item in the code. Code completion also operates during input of assignment statements.

Abstract: A visual development system having an interface which assists a user with input of source code expressions and statements during creation of a computer program is described. The interface includes an Integrated Development Environment (IDE) interface having a code editor with “Code Completion” and “Code Parameter” features for displaying context sensitive pop-up windows within a source code file. Code Completion is implemented at the user interface level by displaying a Code Completion dialog box after the user enters a record or class name followed by a period. For a class, the dialog lists the properties, methods and events appropriate to the class. For a record or structure, the dialog lists the data members of the record. To complete entry of the expression, the user need only select an item from the dialog list, whereupon the system automatically enters the selected item in the code. Code completion also operates during input of assignment statements.