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: 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: 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: Efforts to avoid time-outs during execution of an application in a managed execution environment may be implemented by monitoring memory allocation.

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: 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: 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: 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 to a method for performing garbage collection based on the total memory consumed by managed objects on a heap. The total memory includes heap memory and unmanaged memory. The garbage collector accepts input that indicates the amount of unmanaged memory and associates this amount with the managed object. The garbage collector then adjusts a collection strategy for the managed object based on the input. The input is sent to the garbage collector if the allocated amount meets a certain criteria in comparison with the size of the managed object on the heap. The amount may be automatically disassociated with the managed object when the managed is destroyed or the garbage collector may receive another input that removes the amount from being associated with the managed 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.

Abstract: Systems and methods providing a multiprocessor scalable write barrier to a main memory card table are described. The main memory is divided into multiple cards bit-mapped by the card table. In one aspect, an application store operation (reference) associated with one of the cards is detected. Responsive to detecting the reference, card table bit(s) that are mapped to the card are evaluated. Responsive to determining that the bit(s) have already been marked as dirty, the card table bit(s) are not again marked. This technique effectively reduces the probability of more than a single overlapping write operation to a card table cache line by two or more processors in the system.

Abstract: The techniques and mechanisms described herein are directed to a system for performing garbage collection on a large heap that is divided into several cards which are grouped into bundles. The techniques include initiating a write-watch mechanism to track accesses to a card table that identifies marked cards. The write-watch mechanism provides a list of the written card table locations to a garbage collection process which determines marked bundles based on the list. For each marked bundle, the marked cards within the marked bundle are scanned to identify the accessed objects. The accessed objects are then collected. Because determining the marked bundles is performed at the start of the garbage collection process and not whenever the memory locations within the bundle are accessed, the present technique reduces the overhead associated with bundle marking and allows the efficiency of the garbage collection process to be less dependent on heap size.