Abstract: Disclosed techniques ensure that isolates that are attached to a shared object region will see appropriate class states. In response to an isolate's attempt to instantiate, in such a region, an object that is an instance of a particular class, a bootstrap class' identity is added to that region's bootstrap class list. In response to an isolate's attempt to attach to the region, each class that is both (a) in the region's associated bootstrap class list, and (b) not yet initialized for that isolate, is initialized for that isolate. Thus, those bootstrap classes are seen by that isolate as being in the “initialized” state. In response to an isolate's addition of a particular bootstrap class to the region's list of dependent bootstrap classes, the particular bootstrap class is initialized for each of the isolates attached to the region and for which the bootstrap class is not initialized yet.

Abstract: A method for conditionally sharing dynamically compiled code between different class loaders is provided. In this method, bytecodes of a first class type are compiled into a compiled code if the bytecodes have not been compiled. The locations of sequence of instructions in the compiled code that are loader dependent are then recorded. Thereafter, the loader dependencies in the compiled code are compared to determine whether the compiled code can be used by a method of a second class type. If the loader dependencies of the second class type are different from the loader dependencies of the first class type, the compiled code for the method of the first class type is cloned. Subsequently, portions of the cloned code that are loader dependent are modified to enable the method of the second class type to use the cloned code.

Abstract: The present invention relates to computer systems and methods for providing a memory buffer for use with native and platform-independent software code. In a particular embodiment, the method includes providing a first software program compiled to platform-independent code for execution in a first process of the computer system, providing a second software program compiled to native code for execution in a second process of the computer system, and sending a message from the first process to the second process to request a memory buffer. In another particular embodiment, the computer system includes a processor and a memory. The computer system includes a first process to execute a first software program coded in a safe language, a second process to execute a second software program coded in an unsafe language, and an inter-process communication mechanism that allows data message communication between the first process and the second process.

Abstract: System and method for supporting per-program classpath and class sharing in a multi-tasking virtual machine. A virtual machine may allow each program to specify its classpath independently of other programs classpaths. Tasks that specify identical classpaths for their respective class loaders may share the runtime representation of classes. A multi-tasking virtual machine may generate and compare canonical forms of classpaths to determine which programs may share classes with each other. The runtime representation of a class may be split between shared and private portions of the runtime representation. A shared runtime representation may be associated with multiple private runtime representations. In one embodiment, unique class loader keys and a system dictionary may be used to associate tasks, class loaders and the shared representations of classes.

Abstract: A dynamic delegation chain of executor objects can, at runtime, adapt code units to be executed as isolated computations prior to their execution to comport with current state of an environment. A dynamic delegation chain performs the dynamic runtime adaptation of the code unit in accordance with isolated computations that host the executor objects of the delegation chain. Adapting a code unit prior to execution of the code unit allows adaptation of the code unit to a current state, as well as at least reducing concerns of program integrity.

Abstract: Combining different resource types into a single logical resource can provide a perspective more suitable for managing a given computer program. Resources of different types that have similar characteristics are combined as a single resource type. Resource management policies are applied against the different resource types via the single combination resource type, wherein on a single computer or applied against a cluster of computers.

Abstract: Techniques have been developed whereby concurrency control mechanisms such as nested databases can be expressed in terms of operations implemented by various flexible transaction processing systems. For example, one such implementation of nested databases is particularly suitable for transaction processing systems that provides a lock delegation facility and which allow specification of ignore-conflict relationships between locking capabilities. By providing techniques that support movement of objects from a database to a subdatabase thereof, as well as termination (e.g., commit or abort) of transactions and databases (including subdatabases), transaction processing systems can provide advanced transaction models with unconventional concurrency control mechanisms. Some realizations allow specification of uses of parameters with lock modes and facilitate transformation of such uses into a form suitable for utilization in execution environments that support ignore-conflict relationships.

Abstract: Method and apparatus for locking by sharing lock states. Each resource is associated with a lock state that represents its lock. Lock states are made of one set of transactions per locking mode. Resources may share the same lock state if the state of their respective locks is equal. Locking operations change the association between a resource and a lock state to reflect changes to the resource's lock.

Abstract: Method and apparatus for locking by sharing lock states. Each resource is associated with a lock state that represents its lock. Lock states are made of one set of transactions per locking mode. Resources may share the same lock state if the state of their respective locks is equal. Locking operations change the association between a resource and a lock state to reflect changes to the resource's lock. In one embodiment, a table of immutable lock states (TILS) record the immutable lock states that were created by lock operations in order to avoid duplication of lock states with equal value. Locking operations (acquire and release) on a resource R by a transaction T compute a new lock state value by adding (acquire) or removing (release) T from the lock state associated with R, consult the TILS to retrieve an immutable lock state corresponding to the computed value (and registers one if none was found), and change R's association to refer to the lock state returned by the TILS.

Abstract: Method and apparatus for locking by sharing lock states. Each resource is associated with a lock state that represents its lock. Lock states are made of one set of transactions per locking mode. Resources may share the same lock state if the state of their respective locks is equal. Locking operations change the association between a resource and a lock state to reflect changes to the resource's lock. In one embodiment, a table of immutable lock states (TILS) record the immutable lock states that were created by lock operations in order to avoid duplication of lock states with equal value. Locking operations (acquire and release) on a resource R by a transaction T compute a new lock state value by adding (acquire) or removing (release) T from the lock state associated with R, consult the TILS to retrieve an immutable lock state corresponding to the computed value (and registers one if none was found), and change R's association to refer to the lock state returned by the TILS.

Abstract: Method and apparatus for locking by sharing lock states. Each resource or object has an associated lock state (that may be cached) comprised of transactions that own a lock in a specific mode for the resource. Several resources may share the same lock state. In one embodiment of the invention, a table of immutable lock states (TILS) is utilized to maintain the correct association of locked resources and immutable lock states. To acquire a lock, a new lock state is computed by adding the current transaction to the old lock state. If the new lock state is already in the TILS, the association between the resource and the lock state is updated to reflect the new lock state. If the new lock state is not in the TILS, the new lock state is added to the TILS. To release a lock, the transaction determines the new lock state that will result after removal from the lock state for that resource. The association between the resource and the lock state is then updated to reflect the change.