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