JDK-4408373 : Can we eliminate the -Xmx max heap "glass ceiling"?
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version:
    1.3.0,1.4.0,1.4.1,1.4.2,5.0,5.0u11,6,7 1.3.0,1.4.0,1.4.1,1.4.2,5.0,5.0u11,6,7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,linux,windows_2000,windows_xp generic,linux,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-01-25
  • Updated: 2014-09-04
  • Resolved: 2014-09-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  

Name: krC82822			Date: 01/25/2001

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

The notion of a "maximum heap size" is unique to java, when compared with the
vast majority of "native" applications.  In practice, it puts a "glass ceiling"
on the java application.  Not only does it artificially restrict the java
application from using all of the available native memory, but also it causes
most java applications to (eventually) "hang out" at (75% of) this limit.

I realize that garbage collection theory and real-world implementations are
complex science, and I am not at all an expert.  But here are (hopefully
realistic) suggestions on alternate approaches that seem like they would help
java applications use available native memory more "naturally".  These
suggestions assume the "heap maximum" is gone, and that the JVM is free to use
as much memory as the native OS can provide.

(+) Take "incremental pauseless collection" a step further, let's call
it "aggressive incremental" -- a jvm background thread is constantly gc-ing; if
it senses it's getting "behind" (maybe #alloced/#freed or
size_allocs/size_freed), it steps up its own priority (at the expense of
application speed).  The goal is to never allow too much garbage to be lying
around, with application speed a secondary priority.  A side-benefit is
programmers would be motivated to use objects more efficiently.

(+) For non-incremental, (non-pauseless) gc -- if the java heap is full, do the
most aggressive gc possible before raising the heap size.  After this
aggressive gc cycle, adjust the java heap size (up or down) to allow for
{current used heap} + {new allocation request} + {headroom}.  The "headroom" is
possibly dynamically determined, based on the observed transient memory "peaks"
of the current application.  Meanwhile, if at any time the current java heap is
larger than needed, relocate objects and then return the spare memory to the os.

(+) Replace "-Xmx" with new flags that control:  "heap growth amount", "heap
reduction priority", "overall gc priority (versus speed)", "headroom size", etc.

I guess the bottom line is:  allow us to prioritize "keep memory as small as
possible" at the expense of application speed -- and never use a prohibitive "-
Xmx glass ceiling".  (With all this said, I'd prefer "-Xmx" if the alternatives
would result in _significantly_ slower JVMs.)

I understand Merlin (1.4) may have some new stuff related to controlling gc.
How can we learn more about what's coming?  (Even if you have to disclaim that
it may change or not make the release.)
(Review ID: 115816) 

JDK-6990484 seems to have more in-depth comments.

SUGGESTED FIX The "obvious" answer is to allow an option like "-Xmx90%", that would request that the maximum heap size be 90% of the physical memory of the machine. Seems pretty reasonable. It probably requires some major rewhacking of the argument processing code, though. ###@###.### 2003-04-09 ---------------------------------------------------------------- Another suggestion was to add options -XX:HeapPercentPhysicalMemory= -XX:MaxHeapPercentPhysicalMemory= to be the initial (and minimum) and maximum percent of physical memory to use for the heap. These would fit with the current argument parsing facilities. Everyone agrees that the first one (the initial and minimum) should be called -XX:MinHeapPercentPhysicalMemory=, but also everyone agrees that all the rest of our options are misnamed this way so we should be consistent. We could add a -XX:Min... option, too, if we wanted to start a trend for renaming the old options. ###@###.### 2003-07-07 ----------------------------------------------------------------

EVALUATION It is unlikely that we will eliminate the -Xmx ceiling any time soon. We get a lot of performance out of having side data structures that are 1-to-1 with the heap, so we need the heap to be contiguous. We know how to build "chunked" heaps, but the performance is thought to be significant (10%?), to allow for a feature that you mostly won't use if we can size the heap correctly from command line. This is not high on our list. ###@###.### 2003-04-01 ------------------------------------------------------------------------ With regard to "the ability to soak up whatever RAM is available on the machine', we do have a solution to that. (Is the following weasely enough? I'm not a marketing guy, and can't promise future features.) In the near future one might expect to see an option to set the maximum heap size as a function of the physical memory size on the machine. That would set the maximum size, but not the initial or minimum size, so your application might run happily in much less than the maximum. (As there is now, there would be some slight space overhead for the ability to grow much larger than your live data set.) Such an option might work well if you are the only application on the machine. But it won't work well if two such applications each ask for 90% of the physical memory on the machine, and then proceed to use that much memory. Would such an option be useful to a large class of users? ###@###.### 2003-04-07 ------------------------------------------------------------------------