Microsoft Technology Licensing, LLC

Jan Kotas

Stephen Harris Toub

David Charles Wrighton

Surupa Biswas

Abhinaba Basu

Ori Gershony

Peter F Sollich

Fadi M Hanna

Pranav Krishnamoorthy

Stephane Delcroix

Michael John McLaughlin

Thomas A McDonald

Vance Palmer Morrison

Frank V Peschel-Gallee

Atsushi Kanamori

Jared Porter Parsons

Scott D Mosier

Kumar Gaurav Khanna

Julien Couvreur

Feng Yuan

Zhanliang Chen

Subramanian Ramaswamy

David M Fowler

David M Kean

Ashok Cholpady Kamath

Matthew Cohn

David Jerome Hiniker

David J Hiniker-Roosa

Richard Steele Gibson

Alok Shriram

Michael Rayhelson

Gaye Oncul Kok

Eric N St John

Michael Rousos

Andrew Spenser Gocke

Christopher Sienkiewicz

Tomás Rylek

Anton Lapounov

Pracheeti Nagarkar

Mohammad Rahim Bhojani

Sedar Gokbulut

Divya Swarnkar

Weitao Su

Michael J Rayhelson

A computing system and method for determining if a first software component that has shipped separately from a second software component has been updated. An inline expansion process copies a first method of the first software component into a first method of a second software component is performed so that the copied first method is executable when the second method of the second software component is executed. The first method from the first software component is copied into metadata that is attached to the first method of the second software component. The copy of the first method in the metadata is used to validate that the first method in the first software component has not been updated.

Embedding code from modules across versioning boundaries

Improved compilers recognize interception declarations in source code, and emit code that replaces invocations of specified artifacts with invocations of specified interceptors instead. Source generators proactively modify program behavior in arbitrary desired ways without introducing hidden security violations and without requiring edits by the program's developers. Interception declarations are visible in source code and development tools. In some cases, different invocations of a particular method at respective locations are intercepted by different replacement methods. Replacement methods have identical signatures, or are otherwise compatible. Some interceptors specify optional parameters. Method calls, field accesses, and property calls may be intercepted. Work to modify program behavior is moved in the program lifecycle from runtime to compile time, thus improving runtime performance and eliminating JIT compilation security risks.

Member invocation declarative interception

A computing device including a processor configured to receive source code including a plurality of source code modules. The processor may generate executable code from the source code and assign two or more reload indicators to two or more executable code modules. The processor may execute the executable code. During execution of the executable code, the processor may receive a source code update and generate an executable code update from the source code and the source code update. The processor may apply the executable code update to the executable code to generate updated executable code. The processor may generate a reload ordering of two or more reload operations corresponding to the reload indicators. As specified by the reload ordering, the processor may perform the two or more reload operations at the two or more respective executable code modules. The processor may execute the updated executable code.

Reload ordering for executable code modules

Reuse of a thread-local return data structure to prevent a return data structure from being allocated every time asynchronous functions return. The system returns thread operation from the asynchronous function back to the caller function in a manner that the return data structure can be reused for future asynchronous function returns within that same thread. To do so, the system first accesses data that was generated by the asynchronous function in response to the caller function placing the function call to the asynchronous function. To determine if reuse is appropriate, the system determines that the caller function will use the return data structure as populated only once. If so, the system populates the reusable thread-local return data structure and returns that data structure to the caller.

Thread-local return structure for asynchronous state machine

Representing asynchronous functionality in intermediate code, and then having the runtime compiler, rather than the source code language compiler, declare the corresponding asynchronous state machine. This allows the size of the intermediate code to be smaller thereby facilitating more efficient delivery of the code to end users. Furthermore, the runtime compiler can now use its optimization capability to optimize performance of the asynchronous functionality specific to the actual environment in which the asynchronous work will operate.

Representing asynchronous state machine in intermediate code

Some computing devices have limited resources such as, for example, battery power. When a user ceases to interact with an application, execution of the application can be moved to background and the application can be paused. During the time period in which the application is paused, the application consumes no CPU cycles because executing managed threads of the paused application are stopped, and native threads are prevented from running using asynchronous procedure calls.

Reducing resource consumption by blocking a function associated with an asynchronous procedure call

An instance of universally shared generic code is generated. A runtime parameter enables the size of a stack frame on which local data can be stored to be determined. Dynamically sized locals can be stored on a stack enabling precise garbage collection reporting. One frame of the stack is allocated for each code segment to simplify GC reporting. A reporting region in the frame memory region comprises a count of locals and a location at which the local is found in the stack.

Dynamically sized locals with precise garbage collection reporting

Performant runtime pause with no CPU utilization

One or more identifiers that facilitate efficient native image validation can be generated and stored in an auxiliary file upon pre-compiling of an assembly. The native image can be validated against an assembly from which the native image is generated, among other files that influence the generated contents of the native image, based upon the auxiliary file and included identifiers. Additionally, native image validation can be performed in an increasing cost sequence associated with each identifier included within the auxiliary file.

Light-weight validation of native images

An enhanced binder provides flexibility and certainty when selecting a version of a software library to load, and an enhanced loader prevents a library version vulnerable to a security flaw from being loaded. The binder can perform unification, implicit override, and/or redirection. Implicit override searches assembly-specific locations for an implicit_version, and override the previously chosen unification or other version with the implicit_version when the implicit_version is greater. The implicit_version gets updated with the individual assembly, whereas the unification_version gets updated with the framework. Redirection may override the implicit_version. Unlike redirection, an implicit_version does not recite an explicit range and is found outside application configuration files. The implicit_version is specified implicitly by the assembly without an XML declaration. Vulnerable libraries are not loaded, based on out-of-band metadata placed in response to a list of known out-of-band assemblies, an out-of-band-servicing attribute, or a custom servicing library.

Out-of-band framework libraries within applications

Idle processor cores can be used to compile methods that are likely to be executed by a program based on profile data that is captured during one or more previous executions. Methods that are determined by the profile data to be likely to be used can be compiled eagerly on one or more background threads. Transparency can be achieved by ensuring that module load order is not altered because of the background threads by recording the state of loaded modules after each profiled compilation, persisting that data, and waiting to eagerly compile a method until the method to be compiled and all its dependencies has been loaded by the executing program.

Profile driven multicore background compilation

Routines which are likely to be good candidates for cross-module inlining are automatically identified according to criteria based on service history, compiler inlining criteria, and/or execution performance criteria. Candidates can also be automatically identified by pattern matching codes of routines which satisfy service history, execution performance, and/or compiler criteria. Automatically identified candidate routines are presented in an inlining advisory tool, allowing developers to approve/veto automatically identified candidates, to add other routines, and to either suggest or require that the development tools perform cross-module inlining with particular routines. Changes to a candidate routine can trigger regeneration of native image(s) into which the routine has been compiled.

Cross-module inlining candidate identification

Various technologies and techniques are disclosed for automatically generating native images for a virtual machine environment. A virtual machine environment is provided where application libraries are distributed in an intermediate language format and then compiled at a later point in time. An automatic native generation service is provided that monitors the application libraries and generates a native image for a particular one or more of the application libraries when the service determines that native generation is appropriate. Invalid native images are automatically detected and re-generated. If a load attempt for a particular native image is unsuccessful, then the native image is determined to be invalid. The particular native image is then re-generated automatically.

Automatic native generation

Growing community of inventors

Redmond, WA, United States of America

Jan Kotas