Microsoft Technology Licensing, LLC

Peter Franz Valentin Sollich

Robert Lovejoy Goodwin

Maoni Zhang Stephens

David Charles Wrighton

Ian Michael Bearman

Charles R Salada

Hongtao Yu

Michal Strehovský

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.

Garbage collection prefetching state machine

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.

Arena-based memory management

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.

Compact type layouts

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.

Compatible dictionary layout

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.

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.

Intermediate language support for change resilience

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.

Growing community of inventors

Munich, Germany

Peter Franz Valentin Sollich