Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: A process may utilize multiple garbage collector threads, each having the capability to steal partially-marked object references from an accessible mark stack having additional work that has yet to be processed. A partially-marked object reference may be represented as a pair of entries on a mark stack. A garbage collector thread may utilize an atomic operation to access the pair of entries in a prescribed manner to steal an unprocessed partially-marked object reference. In this manner, the workload of an overloaded garbage collector thread is offloaded to another garbage collector thread that may be idle thereby balancing the workload more evenly among multiple garbage collector threads.

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: Aspects of the subject matter described herein relate to creating and using deltas to modify existing computer code. In aspects, computer code may be translated into a higher level language to make it easier for a software developer to modify the computer code. The translated computer code may be presented by an editing tool that presents a user interface that allows changes to be made to the translated computer code. A delta engine may then determine a delta that indicates the changes to perform on the existing computer code to create computer code that would result from compiling the translated computer code as changed via the editing tool. Later, this delta may be used to change the existing computer code after it has been loaded to add or change debugging hooks or other features of the computer code.

Abstract: Delivering applications to devices. A method includes receiving, at an AppStore, developer provided application code. The method further includes determining anticipated usage of an application based on the application code at end user devices. The method further includes using the determined anticipated usage, optimizing the developer provided application code at the AppStore to optimize for the anticipated usage.

Abstract: A process may utilize multiple garbage collector threads, each having the capability to steal partially-marked object references from an accessible mark stack having additional work that has yet to be processed. A partially-marked object reference may be represented as a pair of entries on a mark stack. A garbage collector thread may utilize an atomic operation to access the pair of entries in a prescribed manner to steal an unprocessed partially-marked object reference. In this manner, the workload of an overloaded garbage collector thread is offloaded to another garbage collector thread that may be idle thereby balancing the workload more evenly among multiple garbage collector threads.

Abstract: A method and system for garbage collecting managed and unmanaged memory that is no longer referenced. The time between allocations is compared with a threshold to determine if the garbage collector needs to collect unused memory. Unmanaged memory referenced by objects in the unused managed memory may be freed during the collection.

Abstract: Aspects of the subject matter described herein relate to creating and using deltas to modify existing computer code. In aspects, computer code may be translated into a higher level language to make it easier for a software developer to modify the computer code. The translated computer code may be presented by an editing tool that presents a user interface that allows changes to be made to the translated computer code. A delta engine may then determine a delta that indicates the changes to perform on the existing computer code to create computer code that would result from compiling the translated computer code as changed via the editing tool. Later, this delta may be used to change the existing computer code after it has been loaded to add or change debugging hooks or other features of the computer code.

Abstract: An automated memory management or garbage collection routine uses a first garbage collection routine to perform garbage collection on new objects, and a second garbage collection routine to perform garbage collection on old objects. The two garbage collection routines are operated concurrently, with each routine separately marking objects to be reclaimed. The second routine may operate in a background mode by traversing a tree of objects from a copy of memory, while the first routine may operate on actual memory.

Abstract: Interfaces are provided to notify of conditions pertaining to memory management. Thus, efforts to avoid time-outs during execution of code in a managed execution environment may be implemented.

Abstract: Efforts to avoid time-outs during execution of an application in a managed execution environment may be implemented by monitoring memory allocation.

Abstract: Dynamic memory management configuration enables certain behavior of an application to be controlled without touching or affecting any executable portion of the application.

Abstract: A finalizer may include a notification that no tolerance for failure or corruption is expected. Any potential failure point, which may be induced by a runtime execution environment routine or subroutine that is associated with the finalizer may then be prepared apart from the finalizer.

Abstract: Deterministic code execution may be recovered for programs or portions thereof by implementing a programmable policy on a system host to escalate the scope of a code discard based on various parameters.

Abstract: The techniques and mechanisms described herein are directed at sharing objects between applications executing in a virtual runtime environment. The techniques include compiling a cpu-independent file to create executable instructions that are associated with an application that is executable in a virtual runtime environment. A constructor associated with a shareable class defined within the cpu-independent file is executed to create an instance of a shareable object. The shareable object is then persisted in a manner such that other applications executing in the virtual runtime environment may access the shareable object. The technique may be performed during pre-JIT compilation or just-in-time compilation of the cpu-independent file. The execution of the constructor is performed at a restricted security level that prevents access to changeable information when generating static data for the static members of the shareable object.

Abstract: A system and method is provided to facilitate communications between object systems. A caller is provided having optimized in-lined functionality when initiating a remote function call between managed and unmanaged object systems, for example. The in-lined functionality includes utilizing direct calls and returns within a calling function. In this manner, pushing additional arguments onto an execution stack because of an external stub reference is mitigated. In addition, one or more code loops can be analyzed to enable stack markers to be “hoisted” and thus pushed a single time instead of each time the calling function executes. Other aspects of the optimized caller provide garbage collection and thread management, security attribute checking on outgoing calls, calling convention considerations, wherein arguments and return values are organized according to the convention utilized by the remote object system, and in-lined marshalling to provide enhanced performance over external stub code references.