Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4408373

Can we eliminate the -Xmx max heap "glass ceiling"?


    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 1.3.0, 1.4.0, 1.4.1, 1.4.2, 5.0, 5.0u11, 6, 7
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
      generic, x86
    • OS:
      generic, linux, windows_2000, windows_xp


      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)


          Issue Links



              • Assignee:
                kryansunw Kevin Ryan (Inactive)
              • Votes:
                0 Vote for this issue
                7 Start watching this issue


                • Created: