United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4741914 RFE: Dynamic heap sizes
4741914 : RFE: Dynamic heap sizes

Details
Type:
Enhancement
Submit Date:
2002-09-05
Status:
Closed
Updated Date:
2012-04-10
Project Name:
JDK
Resolved Date:
2012-04-10
Component:
hotspot
OS:
linux,windows_xp
Sub-Component:
gc
CPU:
x86
Priority:
P4
Resolution:
Duplicate
Affected Versions:
1.4.1,5.0u11,7
Fixed Versions:

Related Reports
Duplicate:
JDK-6559565 - Dynamic upper memory limit please
Duplicate:
JDK-4408373 - Can we eliminate the -Xmx max heap "glass ceiling"?
Relates:
JDK-6749176 - Standard heap memory size (of Applets) too low

Sub Tasks

Description

Name: gm110360			Date: 09/04/2002


FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b18)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b18, mixed mode)

FULL OPERATING SYSTEM VERSION :
doen't apply

A DESCRIPTION OF THE PROBLEM :
Under some circumstances it might be necessary, that a Java
server application needs more memory than it has been given
with the -Xmx parameter.

Reducing the max heap size might require objects to be
relocated in the heap. Increasing not.

Solution might be related to bug#4642192, if bug#4642192
solution requires relocation of objects in the heap.

It's "boring" to restart a Java application just to give it
more memory. This gets more important for server
applications. For example J2EE app servers that get more and
more applications...

EXPECTED VERSUS ACTUAL BEHAVIOR :
Methods like:

public void setMaxHeapSize(long heapSize);
public long getMaxHeapSize();



REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER WORKAROUND :
Restart the whole application.
(Review ID: 164039) 
======================================================================

Comments
EVALUATION

We could build a collector that would allow one to expand the heap.  
The problem would be that there would be some overhead to allowing 
that capability, and it's not clear it's a good tradeoff to always 
penalize performance for the occasional need to expand the heap.

The usual way of working around such problems is to make the server 
fail-safe by having a hot spare.  Then you can load-balance away from 
one of the pair, take it down nicely, and bring it back with a larger 
maximum heap size.  That has a fixed overhead of having the hot spare, 
but you probably want that anyway.

###@###.### 2002-10-24
----------------------------------------------------------------
It might also be possible to build a "chunked" heap.  For example, 
if we allocated the heap in 4GB chunks, each with their own space 
for objects, remembered sets, etc., then we might be able to avoid 
the need for contiguous memory, and could grow the heap as needed 
(in a 64-bit JVM).

###@###.### 2003-08-21
----------------------------------------------------------------
2003-08-21


Hardware and Software, Engineered to Work Together