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.