JDK-4741914 : RFE: Dynamic heap sizes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.1,5.0u11,7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux,windows_xp
  • CPU: x86
  • Submitted: 2002-09-05
  • Updated: 2012-04-10
  • Resolved: 2012-04-10
Related Reports
Duplicate :  
JDK-4408373 - Can we eliminate the -Xmx max heap "glass ceiling"?
Duplicate :  
JDK-6559565 - Dynamic upper memory limit please
Relates :  
JDK-6749176 - Standard heap memory size (of Applets) too low
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 ----------------------------------------------------------------
21-08-2003