System and method for two-tier adaptive heap management in a virtual machine environment

Abstract

In accordance with an embodiment, described herein is a system and method for two-tier adaptive heap management (AHM) in a virtual machine environment, such as a Java virtual machine (JVM). In accordance with an embodiment, a two-tier AHM approach recognizes that more virtual machines can be run on a particular host, or the same number of virtual machines can support higher load while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses, if the heap is divided into tiers, so that a garbage collection policy that minimizes pause time can be used in a first (normal) tier, and a garbage collection policy that favors heap compaction and release of free memory to the host can be used in another (high-heap) tier.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF INVENTION

Embodiments of the invention are generally related to resource management in virtual machines, such as Java virtual machines, and are particularly related to a system and method for adaptive heap memory management in a Java virtual machine environment.

BACKGROUND

Typically, in a Java virtual machine (JVM) environment, a startup parameter such as −Xmx can be used to define the maximum heap memory that a particular virtual machine can use. Subsequently, if the virtual machine needs more memory than the maximum specified memory, it will throw an out-of-memory error (OOME). Generally, an out-of-memory error makes the virtual machine useless, and usually, via another startup parameter or by default, the virtual machine is terminated.

An −Xmx value that is set too high can result in swapping at the operating system (OS) level and/or long old (full) garbage collection pause times which can degrade JVM performance considerably. Although some JVMs can release the unused heap memory back to the OS by compacting the heap, they do so incrementally so as not to adversely affect garbage collection (GC) pause time, and thus a JVM may stay at high heap usage for a long time. This increases the probability of swapping and long old GC pause times.

The problem becomes more pronounced when several JVMs are run on a host machine. A high −Xmx value combined with a conservative heap compaction and release policy will reduce the number of JVMs that can be run on a host without causing swapping. It is not unusual to see many of these JVMs using heap memory, referred to as committed or allocated memory, much less than the maximum specified heap memory for much of the time.

SUMMARY

In accordance with an embodiment, described herein is a system and method for two-tier adaptive heap management (AHM) in a virtual machine environment, such as a Java virtual machine (JVM). In accordance with an embodiment, a two-tier AHM approach recognizes that more virtual machines can be run on a particular host, or the same number of virtual machines can support higher load, while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses, if the heap is divided into tiers, so that a garbage collection policy that minimizes pause time can be used in a first (normal) tier, and a garbage collection policy that favors heap compaction and release of free memory to the host can be used in another (high-heap) tier.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates two-tier adaptive heap management, in accordance with an embodiment, including a JVM whose heap is in a normal tier.

FIG. 2 further illustrates two-tier adaptive heap management, in accordance with an embodiment, including a JVM whose heap is in the red zone.

FIG. 3 illustrates a system for two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

FIG. 4 illustrates two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

FIG. 5 further illustrates two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

FIG. 6 is a flowchart of a method for using two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

DETAILED DESCRIPTION

As described above, typically, in a Java virtual machine (JVM) environment, a startup parameter such as −Xmx can be used to define the maximum heap memory that a particular virtual machine can use. Subsequently, if the virtual machine needs more memory than the maximum specified memory, it will throw an out-of-memory error (DOME). Generally, an out-of-memory error makes the virtual machine useless, and usually, via another startup parameter or by default, the virtual machine is terminated.

In some instances, a virtual machine may throw an out-of-memory error even if the host machine has a lot of free physical or virtual memory. Therefore, application administrators often set the −Xmx value to be equal to or greater than the maximum possible heap memory the virtual machine is expected to use in its lifetime. This may be difficult to determine, since a virtual machine's heap usage may spike for a short time due to several reasons such as startup time or load spike, and those have to be accounted for in the maximum heap usage computation, to avoid out-of-memory errors.

An −Xmx value that is too high can result in swapping at the operating system (OS) level and/or long full garbage collection pause time, which can degrade virtual machine performance considerably. Although some virtual machine environments, such as the JRockit JVM, can free up unused heap memory and return it to the operating system under certain conditions, these conditions generally favor short garbage collection (GC) pause time, and are not aggressive enough in some situations to utilize the memory more efficiently.

The problem becomes more pronounced when several virtual machines need to be run on a host machine.

A high −Xmx value, combined with a conservative heap compaction and release policy, will typically reduce the number of virtual machines that can be run on a host without causing swapping. It is not unusual to see many of these virtual machines using a heap memory (including committed and allocated memory) that is much less than the maximum specified heap memory for much of the time.

For example, in a JRockit JVM environment which uses a genpar garbage collection policy, the virtual machine can release unused heap memory back to the operating system by compacting the heap, which it accomplishes by incremental compaction so as to keep the pause time to a minimum. This frees up unused heap memory slowly, and thus a virtual machine may stay at high heap usage for a long period of time, which in turn increases the probability of swapping.

Adaptive Heap Management (AHM)

In accordance with an embodiment, described herein is a system and method for two-tier adaptive heap management (AHM) in a virtual machine environment, such as a Java virtual machine.

The AHM approach recognizes that more virtual machines can be run on a particular host, or the same number of virtual machines can support higher load, while minimizing the occurrences of out-of-memory errors and swapping, if the heap is divided into two tiers, so that, for example, a garbage collection policy that minimizes pause time can be used in a first (normal) tier, and a garbage collection policy that favors compaction and release of free memory to the host can be used in another (high-heap) tier.

As described herein, the AHM approach to managing virtual machine heap memory is helpful in avoiding out-of-memory errors, swapping, and long old GC pause times associated with temporary spikes, while efficiently utilizing physical memory.

In accordance with an embodiment, a soft limit on the maximum heap memory is introduced. The −Xmx value is treated as a hard limit on memory usage, and has the existing semantics of causing an out-of-memory error when more heap memory is needed. The amount of memory between the soft limit and hard limit is referred to as the red zone. In this manner, the heap can be considered as two tiers: a normal heap tier from zero up to the soft limit; and a special high-heap tier or red zone between the soft limit and the maximum heap size.

In accordance with an embodiment, the garbage collection policy in the normal tier remains unchanged from current garbage collection policies used. The garbage collection policy in the high-heap tier or red zone can try to compact the heap and return the memory to the host quickly, so that the committed memory of the JVM is reduced, thus reducing the full GC pause time for the JVM, and so other virtual machines can use the memory. As such, the red zone can be seen as a zone whose memory is shareable with other virtual machines running on the same host.

In accordance with an embodiment, an adaptive heap management component, such as a JMX MXBean, can be used to define the soft limit and the red zone. In addition, the MXBean can allow an application administrator to specify the memory usage policy for a virtual machine whose heap usage is in the red zone.

For example, a red zone garbage collection policy can allow the application administrator to specify what action to take for a virtual machine whose heap is in the red zone after each old garbage collection. This allows the system to use a very high value for −Xmx and the estimated working set memory size as the soft limit, together with a policy to allow the virtual machine to be in the red zone for a short time, and aggressively compacting and releasing the memory to the operating system to bring the virtual machine's heap usage below the soft limit when the host is running low on free physical memory. This results in better physical memory utilization, and the ability for the virtual machines to handle higher load.

In accordance with an embodiment, the techniques described herein can be used, for example, for maximizing the number of virtual machines that can be run on a host machine, or maximizing the load a fixed set of virtual machine on a host machine can support, while minimizing the number of occurrences of out-of-memory errors, swapping (paging), and long old GC pause times.

While the described approach should not affect the pause time under normal operating conditions, it does favor compaction of the heap to free up enough memory when the host is running low on physical memory. This may cause a one-time pause time rise, in exchange for minimizing out-of-memory errors, swapping, and recurring long old GC pause times.

FIG. 1 illustrates two-tier adaptive heap management, in accordance with an embodiment, including a JVM whose heap is in a normal tier.

As shown in FIG. 1, in accordance with an embodiment, the heap 100 is divided into a plurality of tiers, including a normal tier 104 from zero to a soft limit (SL) 106, in which a first or normal garbage collection policy (e.g., genpar) is used; and a special high-heap or shared tier 108, also referred to as a red zone 110, from the soft limit to the −Xmx value 112, in which a second or AHM garbage collection policy is used (following every normal old garbage collection). For example, the second or AHM garbage collection policy can be one that favors heap compaction and the return of freed memory to the host.

The operation of when and how much memory to free, can be controlled by various parameters, as described in further detail below. Thus, memory can be released to the host more quickly so that other virtual machines can share that memory.

The AHM garbage collection policy can also be designed to accommodate heap usage spikes with little or no swapping. Generally, the use of −Xmx has the same semantics as before, i.e., an attempt to use more heap than that specified by −Xmx will raise an out-of-memory error.

In accordance with an embodiment, as memory is used 112 by the virtual machine, both its actual heap size 114, and its committed or allocated heap size 118 can be determined. Heap space which is committed or allocated, but not in actual use by the virtual machine, is considered free heap space 116.

FIG. 2 further illustrates two-tier adaptive heap management, in accordance with an embodiment, including a JVM whose heap is in the red zone.

As shown in FIG. 2, in accordance with an embodiment, when the heap is being used within the red zone, an AHM garbage collection policy can be used (which in some instances can be used in conjunction with a normal garbage collection policy). For example, as the used heap 122 increases in size 124, such that it's committed heap size 128 is greater than the soft limit representing the beginning of the red zone (even though, as in the illustrated example, there may still be free heap 126 below the soft limit), then the AHM garbage collection policy can be used.

The plurality of tiers, including the normal tier and the high-heap tier or red zone are represented as discrete areas in FIGS. 1 and 2 merely for purposes of illustration. In accordance with an embodiment, the plurality of tiers, including the normal tier and the high-heap tier or red zone need not be provided as such discrete areas within a heap, but instead can represent the level of usage of the heap by a virtual machine at a particular point in time.

In accordance with an embodiment, adaptive heap management permits an application administrator to define the red zone, and a heap memory management policy to be used while the virtual machine is in the red zone. The heap management policy can be defined as a vector of values assigned to variables, for example, as shown in Table 1.

TABLE 1
Variable	Variable	Default
Name	Description	Value
mx	The hard limit on the maximum heap size
	defined by -Xmx start up parameter.
ms	The minimum heap size to be allocated for the
	JVM defined by -Xms startup parameter.
mxsl	The soft limit on the maximum heap size	0.8 * mx
	defined by AHM such that mx ≧ mxsl ≧ ms.	(Alternatively,
	This is specified by the	80% of mx)
	-DMaxHeapMemorySoftLimit startup
	parameter.
mz	The size of the red zone computed as mx − mxsl.
	The size of the red zone should be
	large enough to avoid OOME for
	the applications deployed in the JVM.
nz	The minimum number of old GCs (the term old	0
	GC to refer generically to garbage collection to
	reclaim memory in older generation heap space.
	This is also known as the tenured generation
	GC) that is allowed while the heap is in the red
	zone. Any value greater than zero may cause
	swapping but may allow some time for the JVM
	to go back to its normal heap usage.
mr	The minimum amount of memory to be released	5%
	to the host expressed as percentage of mz. AHM
	will not attempt to compact the memory if
	it cannot release at least (mr * mz)/100
	bytes to the host.
mf	In accordance with an embodiment, the	10%
	minimum amount of committed heap memory
	that must be free after AHM does the heap
	compaction, expressed as a percentage of
	mxsl. AHM will not compact the heap if it
	cannot leave at least (mf * mxsl)/100 bytes of
	heap memory free after compaction.
mhft	The threshold for free physical memory	100 Mb
	of the host.

In accordance with an embodiment, adaptive heap management works only if m_z>0. Therefore, if m_x=m_s, then adaptive heap management is automatically disabled, since there is currently no red zone usage.

If m_u is taken to be the used heap memory size, and m_c the committed heap memory size of the virtual machine (these values can be obtained from a JVM using, e.g., the Java VM MemoryMXBean), in accordance with an embodiment, the AHM component can then instruct the garbage collector to compact the heap using an algorithm as shown below:

gcCount = 0;
// keeps track of the number of consecutive old GCs while the
heap is in the red zone
for each old GC completion do
if (mc < mxsl) {
gcCount = 0; return; //not in the red zone so do nothing
}
gcCount += 1;
mtarget = max(mxsl, (mu +(mxsl * mf/100));
shrunk = false;
if ((mc − mtarget) > (mz * mr/100)){
compact heap size to mtarget
and release the freed memory to the host OS;
shrunk = true;
} if (host free memory > mhft)return;
if (mu ≧ mxsl ){ // used memory is above the soft limit
if(gcCount > nz and forced shutdown is enabled)
terminate the JVM gracefully;
}
else
if (!shrunk)compact the heap to mxsl
end for

Referring to the above algorithm, in accordance with an embodiment, the first “if statement” tests whether the heap is in the red zone.

If the heap is not in the red zone, then nothing is done. However, if the heap is in the red zone, then the system tests to see if enough memory can be freed and still leave minimum free memory required for the virtual machine. If so, then the heap is compacted to the size equal to the larger of used memory size plus minimum free memory size, and soft limit. The remaining memory is then released to the host operating system.

The second “if statement” tests whether the used heap size is greater than the soft limit, and whether the JVM has exceeded the minimum number of old garbage collection allowed while in the red zone, and whether the host physical free memory is below the threshold. If so, the virtual machine is gracefully terminated.

FIG. 3 illustrates a system for two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

As shown in FIG. 3, in accordance with an embodiment, the system can include a computer system or physical server 202 that includes physical resources 204 (for example, CPU, physical memory, network components), an application server 236, and one or more virtual machines/JVMs 210, each of which is associated with a compiler 220, garbage collector 222, available memory space 224, and virtual machine garbage collection interface 226 (for example, in a JRockit environment, the interface may include JRockit's GarbageCollectorMBean methods).

In accordance with an embodiment, each virtual machine includes a heap 230 and a defined red zone 232. In accordance with an embodiment, the JVM also has an AHM component 240 (e.g., a JMX MXBean) suitably configured with AHM variables 242, examples of which as described above, can be used to control the two-tier adaptive heap management of the virtual machine.

In accordance with an embodiment, a console or other administrative tool 150 can allow an application administrator 152 to provide heap management configuration 154, including AHM configuration information 156.

In accordance with an exemplary embodiment, the host free memory computation can take into account factors such as 50% of the memory being used by operating system buffers can be used for the JVM heap.

FIG. 4 illustrates two-tier adaptive heap management in a virtual machine, in accordance with an embodiment. As shown in FIG. 4, each virtual machine includes a heap and a defined red zone. An AHM component (e.g., a JMX MXBean) suitably configured with AHM variables, examples of which as described above, can be used to control 244 the two-tier adaptive heap management of the virtual machine. In accordance with an embodiment, as memory is used by the virtual machine, both its actual heap size and its committed or allocated heap size can be determined. As long as heap usage 245 is within a normal tier, from zero to a soft limit, then the AHM component instructs the garbage collector that a first or normal garbage collection policy should be used 246.

FIG. 5 further illustrates two-tier adaptive heap management in a virtual machine, in accordance with an embodiment. As shown in FIG. 5, if the system determines that heap usage is within a special high-heap tier or red zone, above the soft limit 247 (but less than e.g., the −Xmx value), then the AHM component instructs the garbage collector that a second or AHM garbage collection policy should be used 248.

For example, the second or AHM garbage collection policy can be one that favors heap compaction and the return of freed memory to the host. The garbage collector can then be instructed 249 to compact the heap 250 to the size equal to the used memory size plus minimum free memory size, and the remaining memory released 252 to the host operating system.

FIG. 6 is a flowchart of a method for using two-tier adaptive heap management in a virtual machine, in accordance with an embodiment.

As shown in FIG. 6, at step 280, a computer including memory and one or more virtual machines (e.g., Java Virtual Machine, JVM), with heap for storage of software objects, is provided.

At step 282, an Adaptive Heap Management (AHM) component is defined or otherwise configured to recognize multiple tiers within the heap, including, for each virtual machine, a first tier between zero heap usage and a soft limit, and a second tier (red zone) between the soft limit and a maximum heap memory that the virtual machine is allowed to use (e.g., an −Xmx value).

At step 284, during operation of the one or more virtual machines, the system determines a current heap usage as being within one of the first tier or second tier, and uses the AHM component to adjust the garbage collection policy for use with virtual machine, and perform garbage collection as appropriate.

At step 286, the system continues to reevaluate heap usage as being within one of the first tier or second tier for the one or more virtual machines, and uses the AHM component to readjust garbage collection policy as appropriate.

EXAMPLE IMPLEMENTATIONS

Described below are various embodiments and examples which generally describe use of adaptive heap management with a virtual machine, including, for example a Java virtual machine such as a JRockit JVM. Other embodiments can be provided for use with other types of virtual machine or other types of garbage collected environments.

Example 1

In accordance with an exemplary embodiment, an automatic heap management algorithm can be implemented in an MXBean for use in, for example, an environment including WebLogic Server 10.3.5 and JRockit R28.

In accordance with other embodiments, different implementations can be used for different environments (e.g., an AdaptiveHeapMgmtMXBean for use with (plain) WebLogic Server environments, or an AdaptiveHeapMgmtFMWMXBean for use with Fusion Middleware environments).

In accordance with an embodiment, an AdaptiveHeapMgmtFMWMXBean, which extends AdaptiveHeapMgmtMXBean, can include additional attributes and methods to generate Automatic Diagnostic Repository (ADR) incidents before a JVM is terminated. For example, an ADR incident can encapsulate diagnostic data and include an option to include a heap dump.

In accordance with an embodiment, the AdaptiveHeapMgmtMXBean subscribes to old garbage collection notification, and uses the JVM garbage collection interface (e.g., JRockit's GarbageCollectorMBean methods) to force compaction of the heap and release memory to the host operating system.

In accordance with an embodiment, the garbageCollectorMBean. setAllocatedHeapSizeTarget(heapSizeAllocatedTarget) method is used to set the allocated heap size and garbageCollectorMBean.gc( ) to force the garbage collection with compaction. When the AdaptiveHeapMgmtFMWMXBean is used, its ADR related attributes and methods can be specified. Table 2 illustrates exemplary attributes of AdaptiveHeapMgmtMXBean, in accordance with an embodiment.

TABLE 2
Attribute Name          Description
AdaptiveHeapManage-     Specifies whether adaptive heap management
mentEnabled             feature is enabled or not. Disabling it stops the
                        red zone monitoring only. (default: true).
MaxHeapMemory-          Specifies the heap memory soft limit (mxsl).
SoftLimit               When the committed heap size is above this
                        number adaptive heap management will be
                        activated. The default value is 80% of
                        maximum heap size (80% of the -Xmx value).
RedZoneFreeHeap-        The size of the red zone mz is mx − mxsl where
Percentage              mx is max heap size specified by -Xmx value.
                        The RedZoneFreeHeapPercentage (mf)
                        specifies the percentage of mxsl that should be
                        free after the committed heap is shrunk.
                        (default: 10).
RedZoneMinRe-           The minimum heap memory that can be
leasePercentage         released to the OS (mr), expressed as a
                        percentage of mz. Red zone will not be shrunk
                        if at least this amount of memory cannot be
                        returned to the host considering the free heap
                        that must be kept as specified by
                        RedZoneFreeHeapPercentage. (default: 5).
NumberOfGCsIn-          Specifies the minimum number of consecutive
RedZone                 old GCs in the red zone before action is taken.
                        (default: 0). A value greater than zero should
                        be used if the JVM should be allowed in the
                        red zone for a period of time possibly at the
                        expense of swapping.
HostMemoryThreshold     Specifies the host memory threshold (mhft) to
                        force shutdown of JVMs in the red zone that
                        have NumberOfGCsInRedZone or more
                        consecutive old GCs in the red zone. The force
                        shutdown feature can be disabled by setting
                        ForcedShutdownEnabled to false in which case
                        AHM will aggressively shrink the memory
                        in red zone but will not shutdown the JVM.
                        (default: 100 MB).
ForcedShutdownEnabled   Specifies whether shutdown is enabled when
                        the above condition is met. (default: true).
AdaptiveHeapMgmtState   Shows the current state of adaptive heap
(read-only)             management. The possible values are:
                        Enabled - the adaptive heap management is
                        enabled but the memory usage has not
                        reached MaxHeapMemorySoftLimit.
                        Active - the adaptive heap management is
                        enabled and is actively monitoring the heap
                        which is in the red zone, i.e., heap size is
                        greater than MaxHeapMemorySoftLimit.
                        Disabled - the adaptive heap management is
                        disabled.
NumberOfGCsinRed-       Displays the total number of GCs that happen
ZoneCounter             while the heap is in the red zone. Every time
                        the memory usage goes below
                        MaxHeapMemorySoftLimit this value is
                        reset to 0.
ADRIncidentEnabled      Specifies whether
                        AdaptiveHeapMgmtFMWMXBean
                        will generate an ADR incident
                        when the free heap is less than
                        ADRIncidentHeapThreshold or when
                        the heap is in the red zone and the condition
                        for termination is met. (default: true).
ADRIncidentHeap-        Specifies the amount of free heap from the
Threshold               maximum heap size below which an ADR
                        incident will be generated, if enabled by
                        ADRIncidentEnabled attribute. That is, If the
                        JVM's free heap memory is below this
                        number, an ADR incident will be generated.
                        (default: 20 MB).
TimeBetweenInci-        Specifies the minimum time interval between
dentGeneration          incident generations. Another incident will not
                        be generated within this time of the previous
                        incident. (default: 30 min).
HeapDumpEnabled         Specifies whether a heap dump will be
                        generated and included with the ADR incident.
                        If possible, the heap dump will be included in
                        the ADR incident. Otherwise, it will be put
                        in the heap dump in the location specified by
                        the JVM startup parameters. (default: true).
HeapMemoryFree          Displays the free heap memory. The free heap
(read only)             memory is calculated using the formula (max
                        heap size −
                        Runtime.getRuntime( ).totalMemory( )) +
                        Runtime.getRuntime( ).freeMemory( ).
HeapSizeAllocatedTarget Displays the target set for allocated memory
(read only)             for the heap as returned by the
                        oracle.jrockit.manage-
                        ment.GarbageCollectorMBean.
IncidentGenerated-      Displays the number of incident generated
Counter                 since JVM started.
(read only)
IncidentReportedCounter Displays the number of incident reported since
(read only)             JVM started. Every time an ADR incident
                        generation is requested and the timeout for
                        incident generation is not reached it increments
                        this counter.
IncidentGenerated-      Displays the last time when an ADR incident
LastTime                was generated.
(read only)
HostFreeMemory          Displays the host free memory. It gets the host
(read only)             free memory plus 50% of memory used by OS
                        buffers to calculate this value.
Shutdown State          Displays the state of the JVM shutdown:
(read only)             Enabled - Shut down of JVM is enabled if the
                        conditions specified in
                        AdaptiveHeapMgmtMXBean are met.
                        Active - The JVM has been queued for shutting
                        down. The host free memory will be tested
                        again before the JVM is actually terminated.
                        Disabled - JVM will not be terminated by this
                        MXBean.
StartupSystemProperties Displays the attributes that were specified in
(read only)             the startup command line.

In accordance with an embodiment, the above-described approach was used in an environment including a host with 8 Gb of physical memory, four WebLogic servers (an administration server and three managed servers) to show that AHM did indeed minimize the occurrences of OOME and swapping in an application. The application uses a number of threads deployed in the server. Each thread consumes heap memory from b MB to b+Δh MB that varies with time. The maximum −Xmx value for the JVMs that would accommodate the largest number of threads without causing OOME or swapping was used. Then the AHM MXBean was enabled, and the swapping activity was reduced to near zero.

Example 2

In accordance with an exemplary embodiment that uses JRockit, examination of the JVM heap usage behavior may indicate that, when −Xmx is increased, the committed heap size also increases for the same application (larger free heap). The JRockit JVM GarbageCollectorMBean also provides a setHeapSizeLock(true) to set the max heap size to committed heap size; and a setAllocatedHeapSizeTarget(x) to compact committed heap to size (x±∂).

In accordance with an embodiment, examples of adjustments for the JRockit heap allocation policy can include to lock heap size at the soft limit when committed heap size approaches soft limit to control committed heap growth; unlock to expand beyond a soft limit; or to allow committed memory to go below a soft limit. In accordance with an embodiment, an algorithm for use in such an environment is provided as shown below:

after each Old GC do
if (isHeapSizeLocked( )) {
//unlock heap if free heap is too small or too large
if ((freeCommittedHeapSize < getMinFreeHeapSize( )) ||
(freeCommittedHeapSize > getMaxFreeHeapSize( )))
unlockHeapSize( );
} else {  // heap size is not locked
if(committedHeapSize > (softLimit − delta)
doRedZoneAction(usedHeapSize, committedHeapSize, softLimit);
else {
resetRedZoneCounter( );
if((usedHeapSize + getMinFreeHeapSize( )) < softLimit) {
if((committedHeapSize >= (softLimit − delta)) &&
(committedHeapSize <= (softLimit + delta)))
setHeapSizeLock(true); //lock heap at committed size
else if((committedHeapSize +
getSoftLimitProximityThresholdSize( )) > softLimit)
setAllocatedHeapSizeTarget (softLimit);
// we will lock near this in the next round
}}}
void doRedZoneAction (long usedHeapSize, long
committedHeapSize, long softLimit) {
long targetHeapSize = Math.max((usedHeapSize +
getMinFreeHeapSize( )), softLimit);
boolean heapHasBeenShrunk = false;
if((committedHeapSize − targetHeapSize) >=
getReleaseHeapThresholdSize( )) {
setAllocatedHeapSizeTarget(targetHeapSize);
heapHasBeenShrunk = true;
}
if(getHostFreeMemory( ) > getHostFreeMemoryThreshold( )) return;
// do nothing if there is enough host memory free
if (usedHeapSize >= softLimit) {
if((numberOfGCsInRedZoneCounter >=
getMaxAllowedGCsInRedZone( ))
&& isForcedShutdownEnabled( ))
// Schedule a shutdown. We will check heap again before actual
shutdown
scheduleShutdown( ); }
else
// compact the heap to soft limit if it has not been shrunk
yet
if(!heapHasBeenShrunk) setAllocatedHeapSizeTarget (softLimit);

In accordance with various embodiments, exemplary scenarios to minimize occasional OOME include deploying an AHMMXBean in WLS on JRockit JVM, and starting a WLS server with a higher value for −Xmx (e.g., −Xmx=2 GB instead of 1.6 GB).

To increase load support where possible, the application administrator can start with a soft limit set to working set size; set −Xmx quite high to avoid OOME; and adjust AHMMXBean attribute values accordingly. Values such as AHMMXBean attribute values can be set and monitored with administrative tools or consoles such as, for example Mission Control, EM, or any Mbean browser and used in WLDF Watch rules.

Generally, AHM may not be needed if the host free RAM size is greater than or equal to the product of the maximum heap size a JVM needs, times the number of JVMs desired to be run on the host. AHM may be beneficial if the host free RAM is less than this value but greater than or equally to the product of the working set heap size of JVM, times the number of JVMs desired to be run on the host.

In some instances, an application may have load spikes raising the heap size to the maximum heap size. In such instances, to avoid out-of-memory errors and swapping or performance degradation, an application administrator can set the soft limit to equal the working set heap size, and set the value for −Xmx to equal the maximum heap size, and configure some swap space.

Embodiments of the present invention may be conveniently implemented using one or more conventional general purpose or specialized digital computer, computing device, machine, or microprocessor, including one or more processors, memory and/or computer readable storage media programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.

In some embodiments, the present invention includes a computer program product which is a non-transitory storage medium or computer readable medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. Examples of the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

The foregoing description of embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. For example, although the embodiments and examples described above generally describe use of adaptive heap management with a Java virtual machine, such as a JRockit JVM, other embodiments can be provided for use with other types of virtual machine or other types of garbage collected environments. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated.

Claims

1. A system for two-tier adaptive heap management in a virtual machine, comprising: a computer including a hardware processor and a memory; andan adaptive heap management component, which executes at the computer, and interacts with a virtual machine operating on the computer and associated with a heap, so that a garbage collection policy that minimizes pause time is used with a first tier representative of a first level of usage of the heap, and a garbage collection policy that favors compaction and release of free memory is used with a second tier representative of a higher level of usage of the heap;wherein the adaptive heap management component determines a soft limit on maximum heap size which is greater than a minimum heap size value as defined by a startup parameter, andless than a maximum heap size value as defined by a startup parameter,determines the second tier representative of the higher level of usage of the heap to be a level of heap usage that is between the soft limit on maximum heap size and the maximum heap size value, andevaluates, while the level of heap usage is within the second tier representative of the higher level of usage of the heap, an amount of memory that would be freed by compaction, and, based on the amount of memory that would be freed, determines whether to compact the heap.

2. The system of claim 1, wherein the adaptive heap management component enables more virtual machines to be run on a particular host while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

3. The system of claim 1, wherein the adaptive heap management component enables a same number of virtual machines running on a particular host to support a higher load while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

4. The system of claim 1, wherein the amount of memory that would be freed by compaction is evaluated to determine if sufficient memory can be freed while leaving a minimum free memory required for the virtual machine, and if so then a determination is made to compact the heap.

5. The system of claim 1, whereupon the adaptive heap management component determining to compact the heap, the heap is compacted to a size equal to the larger of: a used memory size plus a minimum free memory size, orthe soft limit on maximum heap size.

6. A method for two-tier adaptive heap management in a virtual machine, comprising: providing, at a computer including a processor and a memory, an adaptive heap management component, which interacts with a virtual machine operating on the computer and associated with a heap, so that a garbage collection policy that minimizes pause time is used with a first tier representative of a first level of usage of the heap, and a garbage collection policy that favors compaction and release of free memory is used with a second tier representative of a higher level of usage of the heap;determining, by the adaptive heap management component, a soft limit on maximum heap size which is greater than a minimum heap size value as defined by a startup parameter, andless than a maximum heap size value as defined by a startup parameter;determining, by the adaptive heap management component, the second tier representative of the higher level of usage of the heap to be a level of heap usage that is between the soft limit on maximum heap size and the maximum heap size value; andevaluating, while the level of heap usage is within the second tier representative of the higher level of usage of the heap, an amount of memory that would be freed by compaction, and, based on the amount of memory that would be freed, determining whether to compact the heap.

7. The method of claim 6, wherein the adaptive heap management component enables more virtual machines to be run on a particular host while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

8. The method of claim 6, wherein the adaptive heap management component enables a same number of virtual machines running on a particular host to support a higher load while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

9. The method of claim 6, wherein the amount of memory that would be freed by compaction is evaluated to determine if sufficient memory can be freed while leaving a minimum free memory required for the virtual machine, and if so then a determination is made to compact the heap.

10. The method of claim 6, whereupon the adaptive heap management component determining to compact the heap, the heap is compacted to a size equal to the larger of: a used memory size plus a minimum free memory size, orthe soft limit on maximum heap size.

11. A non-transitory computer readable storage medium, including instructions stored thereon which when read and executed by one or more computers cause the one or more computers to perform the steps comprising: providing, at a computer including a processor and a memory, an adaptive heap management component, which interacts with a virtual machine operating on the computer and associated with a heap, so that a garbage collection policy that minimizes pause time is used with a first tier representative of a first level of usage of the heap, and a garbage collection policy that favors compaction and release of free memory is used with a second tier representative of a higher level of usage of the heap;determining, by the adaptive heap management component, a soft limit on maximum heap size which is greater than a minimum heap size value as defined by a startup parameter, andless than a maximum heap size value as defined by a startup parameter;determining, by the adaptive heap management component, the second tier representative of the higher level of usage of the heap to be a level of heap usage that is between the soft limit on maximum heap size and the maximum heap size value; andevaluating, while the level of heap usage is within the second tier representative of the higher level of usage of the heap, an amount of memory that would be freed by compaction, and, based on the amount of memory that would be freed, determining whether to compact the heap.

12. The non-transitory computer readable storage medium of claim 11, wherein the adaptive heap management component enables more virtual machines to be run on a particular host while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

13. The non-transitory computer readable storage medium of claim 11, wherein the adaptive heap management component enables a same number of virtual machines running on a particular host to support a higher load while minimizing out-of-memory occurrences, swapping, and long old garbage collection pauses.

14. The non-transitory computer readable storage medium of claim 11, wherein the amount of memory that would be freed by compaction is evaluated to determine if sufficient memory can be freed while leaving a minimum free memory required for the virtual machine, and if so then a determination is made to compact the heap.

15. The non-transitory computer readable storage medium of claim 11, whereupon the adaptive heap management component determining to compact the heap, the heap is compacted to a size equal to the larger of: a used memory size plus a minimum free memory size, orthe soft limit on maximum heap size.