Sun Microsystems, Inc.

Oracle America, Inc.

Hanumantha Rao Susarla

Ajay Kumar

Prakash Khemani

Bala Dutt

Sandhya E

Mukesh Garg

Sridhar Satuloori

Madhurabaratula Srinivas Ramprasad

Seema D Alevoor

Harichandra Reddy Sannapa Reddy

A client-server system may include a distributed store configured to maintain a primary state of session data including one or more attributes. One or more other nodes may include other instances of the primary state. The system may compare the primary state to a benchmark primary state to generate a subset of the attributes of the session data that have been modified in the primary state. Another instance of the primary state may be synchronized with the primary state using the subset of the attributes. In one embodiment, the comparing may include performing binary differencing of binary representations of the primary state and the benchmark primary state to determine the modified attributes. In another embodiment, the comparing may include performing object graph differencing of object graph representations of the primary state and the benchmark primary state to determine the modified attributes.

System and method for state data back-up in a distributed data system

An Induced Multi-threading (IMT) framework may be configured to induce multi-threaded execution in software code. In one embodiment, the IMT framework may include a concurrent code generator configured to receive marked code having one or more blocks of code marked for concurrent execution. Software code initially intended for sequential execution may have been automatically marked by an automated code marker and/or marked manually to generate the marked code. The concurrent code generator may be configured to generate concurrent code from the marked code. The concurrent code may include one or more tasks configured for concurrent execution in place of the one or more marked blocks of code. In one embodiment, the IMT framework may also include a scheduler configured to schedule one or more of the tasks for multi-threaded execution.

Inducing concurrency in software code

A method to instrument software code may comprise marking one or more blocks of code in an application program to provide a marked code. The marking may comprise inserting a marker at each of the one or more blocks according to a marking application programming interface (API). The one or more of the blocks of code marked according to the marking API may be transformed so that one or more functions are performed for the marked blocks. The one or more functions may not be part of the application program. The method may include executing the application program and performing the one or more functions for the marked blocks.

System and method for marking software code

A method and a system for request routing may include a router configured to forward a request to a process. The process may acquire a lock on a memory object. If the process is becomes hung, a data synchronizer may release the lock on the memory object assigned to the process. The lock on the memory object assigned to the process may be released after the process is detected to be hung and after another process requests a lock to the memory object. The router may list inactive processes, and if the process is hung, add the process to the list of inactive processes. The router may be configured to check the inactive list and not route requests to processes on the inactive list. The data synchronizer may be configured to prevent processes on the inactive list from modifying data.

System and method for request routing

A distributed data system may include nodes hosting at least one multi-threaded process operable to access portions of distributed data. A lock mechanism may grant locks to multi-threaded processes for portions of the distributed data. Only a process holding a lock may access a portion corresponding to the lock. Threads of other processes may not access the portion. A process may include one or more threads that may acquire a locks for the distributed data portion on behalf of the process. In one embodiment, the lock mechanism may allow any thread of a process release a lock held by the process. In embodiments, the last thread to access the distributed data portion corresponding to the lock may release the lock in response to no more threads of the process require access to the distributed data portion and/or in response to a request to release the lock.

Last thread lock management for multi-threaded process and distributed data systems

A client-server system may include a primary state of session data. One or more application servers may include client states of the session data and may be configured to access the primary state. The session data may include one or more attributes. The distributed store may lock the primary state for access by a process executing on one of the application servers. Information may be maintained on which attributes are mutably accessed by the process. An object graph comparison of the mutably accessed attributes and a benchmark version of the attributes may be performed to determine which of the mutably accessed attributes were actually modified. The modified attributes may be used to synchronize the primary state with the client state.

System and method for state saves in a distributed data system

An application program may include application modules. One or more of the application modules may each include a dynamic component and static component. The dynamic components and the static components may be configured to function according to an initial set of requirements for the application. A dynamic component generator may receive a new set of requirements for the application and generate updated dynamic components to replace the current dynamic components. The updated dynamic components may be configured to function according to the new set of requirements.

Application programs with dynamic components

A method for inducing multi-threading in software code may use blocks of code as the basis for scheduling and to suggest concurrent execution for each block. The method may comprise marking one or more blocks of code in an application coded for sequential execution to generate marked code. The marking may comprise inserting a marker at each of the one or more blocks to suggest that block for potential concurrent execution. Concurrent code may be generated from the marked code. Generating the concurrent code may comprise analyzing the marked code to estimate performance benefits of concurrently executing the marked blocks of code and determine which marked blocks would meet a performance benefit threshold if executed concurrently. Generating the concurrent code may also comprise transforming one or more of the marked blocks into corresponding concurrently executable tasks. The method may include scheduling one or more of the concurrently executable tasks.

System and method for block-based concurrentization of software code

A client-server system may include a distributed store configured to maintain a primary state of session data. The system may also include one or more application servers that each may include a client state of the session data. The session data may include one or more attributes. In one embodiment, the client state may be accessible by clients of the system. The application server may compare the client state to a benchmark of the client state to determine a subset of the attributes that have been modified in the client state. In some embodiments, the comparison may be a binary differencing or object graph differencing of the client state and the benchmark of the client state to locate the modified attributes. The distributed store may synchronize the primary state with the client state using the subset of the attributes.

Object mutation determination for incremental state saves

A client-server system may include a primary state of session data. Application servers may include client states of the session data and may access the primary state. The session data may include attributes. The distributed store may provide locked access to the primary state to processes executing within the application servers. While one process has locked access, other processes are not allowed to access the primary state. In one embodiment, the distributed store provides locked access to portions of the primary state to threads executing within a process with locked access. While a portion of the primary state is locked for a thread, other threads cannot access the portion. In one embodiment, the distributed store may request the process to release the locked access. The process may release the locked access in response to the request. In one embodiment, the process may release the locked access when no longer needed.

Lock mechanism for a distributed data system

A scheduler may be configured to schedule a plurality of blocks of concurrent code for multi-threaded execution. The scheduler may be configured to initiate multi-threaded execution of the blocks of concurrent code in an order determined by block-level performance criteria for the blocks of concurrent code to reduce overall execution time of the concurrent code. In one embodiment, the scheduler may be configured to schedule code blocks having a longer run time ahead of blocks having a shorter run time. The scheduler may be configured to schedule a group of said blocks based on a goal of each of the blocks of the group completing execution at approximately the same time. The scheduler may also be configured to initiate multi-threaded execution of each block of the group at different times according to the block-level performance criteria to the goal.

System and method for goal-based scheduling of blocks of code for concurrent execution

Embodiments of a system and method for providing class dependency graph-based class loading and reloading may be used to segregate namespaces in a graph-centric way, and may provide a set of normalized topologies that may be used to efficiently support hot-swapping of programmatic logic such as classes, applets, and beans, among other applications. Embodiments may provide a domain-independent, flexible and robust namespace segregation technique that is based on the dependency between the various classes and not on details like the roles the classes play. The problem of segregating namespaces is formulated as a graph theory problem, and a solution is sought through graph techniques. The graph may be normalized by identifying and grouping interdependent classes and non-interdependent classes in separate groups. A directed dependency relationship of the groups may be determined using the relationships between the member classes of the groups.

Class dependency graph-based class loading and reloading

A system and method for providing dynamic class reloading using a modular, pluggable and maintainable class loader is described. Each application in an application server (or alternatively in any implementation) may include a dynamic class loader module. The class loader module may include a hierarchical stack of class loaders. Each module in the application may be associated with its own class loader. Each class loader may be responsible for loading one or more classes. When a class is changed, the changed class may be detected by the class loader module. Any notification for a class change may come to the class loader controller so that the concerned class loader can be replaced. The class loaders for all classes that depend on the changed class may also be replaced. The replaced class loaders may then reload the affected classes.

Growing community of inventors

Bengaluru, India

Hanumantha Rao Susarla