United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4408373 : Can we eliminate the -Xmx max heap "glass ceiling"?

Details
Type:
Enhancement
Submit Date:
2001-01-25
Status:
Closed
Updated Date:
2014-09-04
Project Name:
JDK
Resolved Date:
2014-09-04
Component:
hotspot
OS:
linux,generic,windows_xp,windows_2000
Sub-Component:
gc
CPU:
x86,generic
Priority:
P4
Resolution:
Duplicate
Affected Versions:
1.3.0,1.4.0,1.4.1,1.4.2,5.0,5.0u11,6,7
Fixed Versions:
9

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description

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) 
======================================================================

                                    

Comments
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
------------------------------------------------------------------------
                                     
2003-04-07
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
----------------------------------------------------------------
                                     
2003-07-07
JDK-6990484 seems to have more in-depth comments.
                                     
2014-09-04



Hardware and Software, Engineered to Work Together