Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Code components can be distributed as executable code (e.g., binaries) in a format that includes both machine-independent intermediate code (e.g., bytecode, CIL, etc.) and ahead-of-time compiled native code. The native code is executed if the execution environment is compatible with the native code. If the execution environment is incompatible with the native code, execution falls back to execution from intermediate code.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.