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

Spec: MemoryUsage should not allow max < committed



      The current spec of MemoryUsage allows max <= committed. BEA raises
      their concern that max <= committed is confusing. Besides, there is no
      well-defined "capacity" which has the same meaning of Runtime.totalMemory.

      Runtime.totalMemory is the total amount of memory currently available for
      current and future objects, measured in bytes.

      For a memory pool, capacity without committing more memory is
         min(committed, max) if max is defined; otherwise, comitted

      We propose to change "max" to be maximum amount of memory in this
      memory pool which is well-defined and clear. committed will be
      the capacity of a memory pool without committing more memory.

      The spec allows max <= committed to take care of the cases that part
      of the committed memory of a memory pool is reserved for VM internal
      processing. In hotspot implementation, it has two survivor spaces
      and only one can be used for allocation. The other is reserved for
      GC time use. With the proposed spec change, we will expose one
      survivor space as a memory pool and hide the other which is unused
      except at GC time.

      In the future, we should consider adding a SYSTEM MemoryType for
      any pool that is designated for VM internal use but the memory
      consumed by that pool is still accountable via the management API.

      This would require a spec change and hotspot implementation change.




            • Assignee:
              mchung Mandy Chung
              mchung Mandy Chung
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: