New! View global litigation for patent families

US20040123303A1 - System and method for managing memory resources in a shared memory system - Google Patents

System and method for managing memory resources in a shared memory system Download PDF

Info

Publication number
US20040123303A1
US20040123303A1 US10383302 US38330203A US2004123303A1 US 20040123303 A1 US20040123303 A1 US 20040123303A1 US 10383302 US10383302 US 10383302 US 38330203 A US38330203 A US 38330203A US 2004123303 A1 US2004123303 A1 US 2004123303A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
memory
user
object
objects
system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10383302
Other versions
US7370327B2 (en )
Inventor
Martin Trotter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRICAL DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for programme control, e.g. control unit
    • G06F9/06Arrangements for programme control, e.g. control unit using stored programme, i.e. using internal store of processing equipment to receive and retain programme
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure

Abstract

A method is provided for managing memory resources in a shared memory system. A point is identified (10) at which memory usage will be constrained. An object pertaining to an active user of the system is identified (20), and further objects related to this object are also found (30). A user memory footprint is then determined (40) from the footprints of the identified objects. Different constraint options are identified (50) and one of these is used to constrain (60) the user memory footprint. In this way the memory used by individual users may be tracked and constrained without having to place all the work from users into separate JVMs. Therefore the ‘bursty’ nature of memory consumption by multiple users can be summed to result in a JVM which exhibits much less bursty memory requirements and allows individual users to have relatively relaxed constraints.

Description

    TECHNICAL FIELD OF THE INVENTION
  • [0001]
    This invention relates to shared memory systems and particularly (though not exclusively) to shared usage of a JVM (Java Virtual Machine) by many remote users. “JAVA” is a trademark of Sun Microsystems Inc.
  • BACKGROUND OF THE INVENTION
  • [0002]
    In the field of this invention it is known that in a JVM shared by many remote users, any one of the users could individually exhaust all the memory available to the JVM. The JVM itself imposes limits on the memory usage by all users of that JVM. These limits are imposed by specifying a maximum heap size limit.
  • [0003]
    A ‘garbage collector’ analyses the live memory within the heap by starting from a set of root references on the stacks (in global references such as class statics) and by proceeding to mark all objects thus referenced.
  • [0004]
    However, this approach has the disadvantage(s) that the single JVM limit constrains all the potential users of a multi-user JVM to the same level and makes it possible for one user to mount a denial of service attack simply by over-consuming memory.
  • [0005]
    The techniques used by garbage collection to mark the live memory are effective but are not sufficient to identify the objects created by a given user and thus determine which user or users are over-consuming memory.
  • [0006]
    One possible solution to this problem would be to define the concept of an ‘Isolate’ which can be given some set of resources and allowed to consume them until it fails. If the isolate is implemented as a separate JVM then the scale of any resultant damage can be obviously limited.
  • [0007]
    However, defining multiple ‘isolates’ would lead to poor utilisation of resources since each isolate must be allowed to grow individually to the resource limits.
  • [0008]
    A need therefore exists for a method and system for managing memory resources in a shared memory system (such as a JVM) wherein the abovementioned disadvantage(s) may be alleviated.
  • SUMMARY OF THE INVENTION
  • [0009]
    In accordance with a first aspect of the present invention there is provided a method for managing memory resources in a shared memory system having a plurality of users and having a total memory footprint, the method comprising: determining that the total memory footprint of the system has reached a predetermined level; identifying at least one object pertaining to a user of the system; and determining a user memory footprint by calculating the memory footprint of the at least one object, and constraining the user memory footprint such that the total memory footprint of the system is limited.
  • [0010]
    In accordance with a second aspect of the present invention there is provided a system for imposing memory constraints on a user of a shared memory system, according to the first aspect.
  • [0011]
    According to a third aspect, the invention provides a computer program product for, when run on a computer system, instructing the computer system to carry out the method of the first aspect.
  • [0012]
    Preferably, identifying at least one object comprises identifying a principal object and identifying at least one further object related to the principal object. The principal object and the at least one further object preferably represent substantially all objects relating to the user.
  • [0013]
    The system preferably comprises a Java Virtual Machine. Preferably identifying the at least one further object comprises performing a recursive marking operation which stops at one of: an object which is already known; an object identified as a global object; and a class which is inherited by the user.
  • [0014]
    Constraining the user memory footprint preferably includes terminating incoming sessions from the user. Alternatively, constraining the user memory footprint preferably includes stopping threads running on behalf of the user.
  • [0015]
    The size of individual objects allocated to the user is preferably limited.
  • [0016]
    In this way the memory used by individual users may be tracked and constrained without having to place all the work from individual users into separate JVMs. Therefore, the ‘bursty’ nature of memory consumption by multiple users can be summed to result in a JVM which exhibits much less bursty memory requirements whilst at the same time allowing individual users to have relatively relaxed constraints.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0017]
    One system and method for managing memory resources in a shared memory system incorporating the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
  • [0018]
    [0018]FIG. 1 shows a block schematic diagram illustrating steps of a method for memory allocation in a shared memory system incorporating the present invention; and
  • [0019]
    [0019]FIG. 2 shows an illustrative block diagram showing objects identified by the method of FIG. 1.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • [0020]
    Referring to FIG. 1, there is shown an illustrative flow chart of the steps involved in limiting memory consumed by a given user. These steps are implemented in a software environment (hereafter referred to as a ‘container’).
  • [0021]
    At box 10, the identification of the point at which to constrain memory is performed. The ideal point is just prior to a heap growth event but this is not easy to implement in practice.
  • [0022]
    Three possible methods for achieving the function of box 10 are described below.
  • [0023]
    The first involves periodically sampling the value of Runtime.totalMemory( ) and imposing the constraint when it reaches a pre-determined value.
  • [0024]
    The second involves creating a WeakReference which will be queued after a garbage collection cycle in which the heap was expanded.
  • [0025]
    The third alternative is to employ a monitoring event from JVMPI (JVM Performance Interface) or the newly proposed tools interface (JVMTI) to provide an indication that the garbage collector has just done something.
  • [0026]
    The monitoring event would ideally be a ‘heap growth’ event but in the worst case the simple ‘garbage collection’ event would suffice.
  • [0027]
    When that event is generated, Runtime.totalMemory and Runtime.freeMemory would be sampled in order to determine if the JVM is approaching a point at which further analysis of memory usage should be undertaken.
  • [0028]
    In this way, when it becomes necessary to constrain memory, the next step 20 is performed, namely the identification of a first or principal object pertaining to the currently executing user. This is performed using well known techniques. In essence there will exist a set of principal objects representing individual users. These principal objects facilitate the location of all session objects representing active connections which the user may have and also objects representing any active threads which the user has been allowed to create.
  • [0029]
    Typically it is preferable that users do not create threads but that their processing requirements are met using message receive methods of session or conversation objects.
  • [0030]
    In box 30, a reflection procedure is invoked to find the closure of objects referenced from that principal object.
  • [0031]
    At the first level this will be the set of session objects which represent the connections through which the user is driving work into the JVM. During the identification of this set of objects it is necessary to verify that any one identified object:
  • [0032]
    A) has not already been identified as part of the set;
  • [0033]
    B) has not been assigned to public or other fields in classes which are not directly owned by the user; and,
  • [0034]
    C) is not an instance of one of the container implementation classes, possibly the container itself.
  • [0035]
    These exceptions are illustrated by box 35. If any of the above conditions are true, the object must be omitted from the set.
  • [0036]
    Case A) above is relatively easy to prevent by maintaining a record of previously identified set members.
  • [0037]
    Case C) is handled by abandoning the trace at that point once this situation has been detected.
  • [0038]
    For Case B), the preferred technique is to leave untraced any Container implementation classes which the user is intended to extend as part of the user's implementation and which may contain references to objects not primarily associated with the user. In addition the well known classfile modification techniques would be employed to prevent the user assigning objects which are personal to the user into static fields of Container or J2SE (Java 2 Standard Edition) classes and thus ‘hiding’ such data from this tracing step.
  • [0039]
    Referring now also to FIG. 2, there is shown an illustrative block diagram showing a number of objects relating to a user.
  • [0040]
    A principal object 100 which has a base class inheritance represents the user. ‘X’ 105 is an untraced reference from the base class field of the object 100. This is because references from the base class fields are not traced.
  • [0041]
    Objects 110 and 120 also have base class inheritances, and these are found from tracing the non-base class references of the principal object 100. ‘X’s 115 and 125 respectively are untraced references from the base class fields of the objects 110 and 120 respectively.
  • [0042]
    Objects 130 and 140 are objects traced via the non-base class references of objects 110 and 120 respectively. Object 150 is a global object and is therefore untraced (shown by ‘X’ 135).
  • [0043]
    Objects 160 and 170 are multiply traced, object 160 being referenced by objects 130 and 140 respectively, and object 170 being referenced by objects 120 and 140 respectively. This is why it is important for a record to be kept of traced objects, so that no object is counted more than once.
  • [0044]
    By the above means each of the objects relating to the user are identified, and referring again to FIG. 1, at box 40, the sum of the memory owned (used) by the user is quantified from these identified objects.
  • [0045]
    At box 50, the imposition of resource limits is then selected. The memory usage by the user may be constrained either by terminating incoming sessions from the user or stopping threads running on behalf of the user.
  • [0046]
    Finally, at box 60, the selected constraint is applied to the user.
  • [0047]
    There are two further problems to handle: threads which may be associated with the user and requests for large amounts of memory.
  • [0048]
    If a user requests a large piece of memory then the above checks may not help. The memory subsystem will be handed the request (for example, for a huge array of long bytes with 2**31 elements).
  • [0049]
    It will attempt to run a garbage collection event but in general the task will fail and it will be forced to give up with an OutOfMemoryError which will be potentially caught by the user code and retried leading to a tight CPU consuming loop; in other words a denial of service opportunity. To avoid this situation it is assumed that the JVM will itself be able to impose limits on the size of large objects allocated by the current thread.
  • [0050]
    This limit will be defined by putting a new method setObjectSizeLimit (long bytes) on a thread sub-class which will prevent the creation of large objects which would otherwise cause this problem. It would also be possible to have the JVM impose some arbitrary limit on all threads in this environment. At the very least a user must be prevented from turning this situation into a way to consume endless CPU catching out of memory errors and thus mounting a denial of service attack.
  • [0051]
    If threads are permitted to be associated with a user then the above checks will not suffice since the user can simply define some local variables in the thread and reference any amount of memory from them. In this situation a way must be found to either trace these local variables or to make these threads leave their run method during the tracing. The first option will imply the introduction of another new method on the thread sub-class, such as:
  • [0052]
    int findLocalReferences(Object[ ] refs);
  • [0053]
    Such a method would suffice and would be a native method. Obviously that technique requires some involvement from the JVM and is thus not appropriate for a class which will be used with a standard J2SE implementation.
  • [0054]
    A second option is to impose some limit on the length of time a run method can execute. Any thread which fails to complete within that limit could simply be stopped using Thread.stop. Typically all the users threads would be stopped if any of them caused such a problem.
  • [0055]
    Also it would need to be ensured that threads are not stopped whilst in the process of making updates to shared resources. This model would effectively force the user to break the work into small pieces and pass it from thread to thread until completion. If this method is chosen then it could be optimised for use within the JVM by maintaining a thread pool and using it to drive the successive run methods. The user's work can be stopped at any point by simply avoiding calling the run methods of the user's thread objects until after the memory scan is complete. This whole approach makes no change to standard Java syntax but obviously changes the semantics of the run method to include the statement must not run for more than X ms′. It is worth noting that, providing the threads are fairly well behaved and don't consume large amounts of memory, the JVM heap will stay below some threshold value and none of the checking mentioned so far will be done.
  • [0056]
    Hence for well behaved users the overhead will be zero. The likely outcome is that badly behaved code or users will be quickly identified and prevented from running at all. The intent of all this work is to find a way to identify such ‘rogues’ and a way to deal with them once found.
  • [0057]
    In this way substantially all of the extant objects created by a given user are identified, and a limit is placed both on the number of objects and on the total size. The result will define something akin to a ‘flexible isolate’ in that there will be no need to decide once and for all what the resource limits for a given isolate should be; they can be varied during the lifetime of the JVM as policies change.
  • [0058]
    It will be understood that the embodiment described above provides the following advantages:
  • [0059]
    The memory used by individual users can be tracked and constrained without having to place all the work from individual users into separate JVMs. The net effect is that the ‘bursty’ nature of memory consumption by multiple users can be summed to result in a JVM which exhibits much less bursty memory requirements while at the same time allowing individual users to have relatively relaxed constraints.
  • [0060]
    It will be appreciated by a person skilled in the art that alternative embodiments to those described above are possible.
  • [0061]
    For example the embodiment above relates to a JVM, but other embodiments suitable for other shared memory systems are contemplated, in which objects and processes associated with those systems would be utilised instead of the JVM objects and processes described above.

Claims (17)

    What is claimed is:
  1. 1. A method for managing memory resources in a shared memory system having a plurality of users and having a total memory footprint, the method comprising:
    determining that the total memory footprint of the system has reached a predetermined level;
    identifying at least one object pertaining to a user of the system; and
    determining a user memory footprint by calculating the memory footprint of the at least one object, and
    constraining the user memory footprint such that the total memory footprint of the system is limited.
  2. 2. The method of claim 1 wherein the step of identifying at least one object comprises the step of identifying a principal object and the subsequent step of identifying at least one further object related to the principal object.
  3. 3. A shared memory system having a plurality of users and having a total memory footprint, the system including:
    means for determining that the total memory footprint of the system has reached a predetermined level;
    means for identifying at least one object pertaining to a user of the system; and
    means for determining a user memory footprint by calculating the memory footprint of the at least one object, and
    means for constraining the user memory footprint such that the total memory footprint of the system is limited.
  4. 4. The system of claim 3 wherein the means for identifying the at least one object comprises means for identifying a principal object and means for identifying at least one further object related to the principal object.
  5. 5. The method of claim 2 wherein the principal object and the at least one further object represent substantially all objects relating to the user.
  6. 6. The method of claim 1 wherein the system comprises a Java Virtual Machine.
  7. 7. The method of claim 6 wherein identifying the at least one further object comprises performing a recursive marking operation which stops at one of:
    an object which is already known;
    an object identified as a global object; and
    a class which is inherited by the user.
  8. 8. The method of claim 1 wherein constraining the user memory footprint includes terminating incoming sessions from the user.
  9. 9. The method of claim 1 wherein constraining the user memory footprint includes stopping threads running on behalf of the user.
  10. 10. The method of claim 1 further comprising limiting the size of individual objects allocated to the user.
  11. 11. The system of claim 3 wherein the principal object and the at least one further object represent substantially all objects relating to the user.
  12. 12. The system of claim 3 wherein the system comprises a Java Virtual Machine.
  13. 13. The system of claim 12 wherein identifying the at least one further object comprises performing a recursive marking operation which stops at one of:
    an object which is already known;
    an object identified as a global object; and
    a class which is inherited by the user.
  14. 14. The system of claim 3 wherein constraining the user memory footprint includes terminating incoming sessions from the user.
  15. 15. The system of claim 3 wherein constraining the user memory footprint includes stopping threads running on behalf of the user.
  16. 16. The system of claim 3 further comprising limiting the size of individual objects allocated to the user.
  17. 17. A computer program product stored on a computer readable storage medium for, when run on a computer system, instructing the computer system to carry out the method of claim 1.
US10383302 2002-12-19 2003-03-06 Method for managing memory resources in a shared memory system Expired - Fee Related US7370327B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB0229670.5 2002-12-19
GB0229670A GB0229670D0 (en) 2002-12-19 2002-12-19 System and method for managing memory resources in a shared memory system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12033632 US8122454B2 (en) 2002-12-19 2008-02-19 Managing memory resources in a shared memory system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12033632 Continuation US8122454B2 (en) 2002-12-19 2008-02-19 Managing memory resources in a shared memory system

Publications (2)

Publication Number Publication Date
US20040123303A1 true true US20040123303A1 (en) 2004-06-24
US7370327B2 US7370327B2 (en) 2008-05-06

Family

ID=9950050

Family Applications (2)

Application Number Title Priority Date Filing Date
US10383302 Expired - Fee Related US7370327B2 (en) 2002-12-19 2003-03-06 Method for managing memory resources in a shared memory system
US12033632 Expired - Fee Related US8122454B2 (en) 2002-12-19 2008-02-19 Managing memory resources in a shared memory system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12033632 Expired - Fee Related US8122454B2 (en) 2002-12-19 2008-02-19 Managing memory resources in a shared memory system

Country Status (2)

Country Link
US (2) US7370327B2 (en)
GB (1) GB0229670D0 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060010444A1 (en) * 2004-07-09 2006-01-12 Seidman David I Lock contention pinpointing
US20060015841A1 (en) * 2004-06-30 2006-01-19 International Business Machines Corporation Control on demand data center service configurations
US20060031813A1 (en) * 2004-07-22 2006-02-09 International Business Machines Corporation On demand data center service end-to-end service provisioning and management
US7231541B1 (en) * 2004-02-17 2007-06-12 Unisys Corporation Method for predictably feeding and consuming RAM memory to recognize over-consumption of resources

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813082B2 (en) * 2006-06-22 2014-08-19 International Business Machines Corporation Thread priority based on object creation rates

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
US6564223B1 (en) * 1999-09-30 2003-05-13 Oracle Corp. Method and article for managing references to external objects in a runtime environment
US6604182B1 (en) * 1999-10-21 2003-08-05 Oracle Corp. Methods for managing memory in a run-time environment including activation and deactivation of objects
US20030187989A1 (en) * 2002-03-27 2003-10-02 Patrick Petit System and method for determining memory usage in sizing a portal server
US20040024798A1 (en) * 2002-07-31 2004-02-05 Texas Instruments Incorporated Conditional garbage based on monitoring to improve real time performance
US20040111725A1 (en) * 2002-11-08 2004-06-10 Bhaskar Srinivasan Systems and methods for policy-based application management
US6807551B2 (en) * 2002-04-22 2004-10-19 Sun Microsystems Inc. Measuring maximum memory requirement of an application at any point through continuous use of garbage collector
US6865585B1 (en) * 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
US6938254B1 (en) * 1997-05-06 2005-08-30 Microsoft Corporation Controlling memory usage in systems having limited physical memory
US7028298B1 (en) * 1999-09-10 2006-04-11 Sun Microsystems, Inc. Apparatus and methods for managing resource usage
US7086060B2 (en) * 2001-02-15 2006-08-01 Sun Microsystems, Inc. Method for programmatic representation and enforcement of resource controls
US7162605B2 (en) * 2004-06-24 2007-01-09 International Business Machines Corporation Method and system for obtaining memory usage information for a heap when a peak live count is updated

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6519594B1 (en) * 1998-11-14 2003-02-11 Sony Electronics, Inc. Computer-implemented sharing of java classes for increased memory efficiency and communication method
US6725241B1 (en) * 1999-03-31 2004-04-20 International Business Machines Corporation Method and apparatus for freeing memory in a data processing system

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6938254B1 (en) * 1997-05-06 2005-08-30 Microsoft Corporation Controlling memory usage in systems having limited physical memory
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US7028298B1 (en) * 1999-09-10 2006-04-11 Sun Microsystems, Inc. Apparatus and methods for managing resource usage
US6564223B1 (en) * 1999-09-30 2003-05-13 Oracle Corp. Method and article for managing references to external objects in a runtime environment
US6604182B1 (en) * 1999-10-21 2003-08-05 Oracle Corp. Methods for managing memory in a run-time environment including activation and deactivation of objects
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
US6865585B1 (en) * 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
US7086060B2 (en) * 2001-02-15 2006-08-01 Sun Microsystems, Inc. Method for programmatic representation and enforcement of resource controls
US20030187989A1 (en) * 2002-03-27 2003-10-02 Patrick Petit System and method for determining memory usage in sizing a portal server
US6807551B2 (en) * 2002-04-22 2004-10-19 Sun Microsystems Inc. Measuring maximum memory requirement of an application at any point through continuous use of garbage collector
US20040024798A1 (en) * 2002-07-31 2004-02-05 Texas Instruments Incorporated Conditional garbage based on monitoring to improve real time performance
US20040111725A1 (en) * 2002-11-08 2004-06-10 Bhaskar Srinivasan Systems and methods for policy-based application management
US7162605B2 (en) * 2004-06-24 2007-01-09 International Business Machines Corporation Method and system for obtaining memory usage information for a heap when a peak live count is updated

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7231541B1 (en) * 2004-02-17 2007-06-12 Unisys Corporation Method for predictably feeding and consuming RAM memory to recognize over-consumption of resources
US20060015841A1 (en) * 2004-06-30 2006-01-19 International Business Machines Corporation Control on demand data center service configurations
US20060010444A1 (en) * 2004-07-09 2006-01-12 Seidman David I Lock contention pinpointing
US8046760B2 (en) * 2004-07-09 2011-10-25 Hewlett-Packard Development Company, L.P. Lock contention pinpointing
US20060031813A1 (en) * 2004-07-22 2006-02-09 International Business Machines Corporation On demand data center service end-to-end service provisioning and management

Also Published As

Publication number Publication date Type
US7370327B2 (en) 2008-05-06 grant
US20080216083A1 (en) 2008-09-04 application
US8122454B2 (en) 2012-02-21 grant
GB0229670D0 (en) 2003-01-29 grant

Similar Documents

Publication Publication Date Title
Von Behren et al. Capriccio: scalable threads for internet services
Bishop Computer systems with a very large address space and garbage collection
US6694507B2 (en) Method and apparatus for analyzing performance of object oriented programming code
US6381735B1 (en) Dynamic classification of sections of software
US6732357B1 (en) Determining and compensating for temporal overhead in trace record generation and processing
US6272674B1 (en) Method and apparatus for loading a Java application program
US6751789B1 (en) Method and system for periodic trace sampling for real-time generation of segments of call stack trees augmented with call stack position determination
US7069281B2 (en) Efficient collocation of evacuated objects in a copying garbage collector using variably filled local allocation buffers
US7111294B2 (en) Thread-specific heaps
US6658652B1 (en) Method and system for shadow heap memory leak detection and other heap analysis in an object-oriented environment during real-time trace processing
US6817011B1 (en) Memory allocation profiling to discover high frequency allocators
Hofmeister et al. Dynamic reconfiguration in distributed systems: Adapting software modules for replacement
US6854114B1 (en) Using a virtual machine instance as the basic unit of user execution in a server environment
US6857120B1 (en) Method for characterizing program execution by periodic call stack inspection
US6275983B1 (en) Object-oriented operating system
US6240548B1 (en) Method and apparatus for performing byte-code optimization during pauses
US6662359B1 (en) System and method for injecting hooks into Java classes to handle exception and finalization processing
US6006235A (en) Method and apparatus for invoking a stored procedure or a user defined interpreted language function in a database management system
US20030174572A1 (en) Non-blocking memory management mechanism for supporting dynamic-sized data structures
US20020055941A1 (en) Computer system with two heaps in contiguous storage
US6507805B1 (en) Method and system for compensating for instrumentation overhead in trace data by detecting minimum event times
US6253317B1 (en) Method and apparatus for providing and handling traps
US20020120428A1 (en) Topological, on-the-fly classification of objects into a global set and local sets
US6625808B1 (en) Method and apparatus for facilitating memory management in a program comprised of heterogeneous components
US5636376A (en) System and method for selectively and contemporaneously monitoring processes in a multiprocessing server

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TROTTER, MARTIN JOHN;REEL/FRAME:013872/0889

Effective date: 20030219

FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
FP Expired due to failure to pay maintenance fee

Effective date: 20160506