Test checking that native memory is returning to the system.

---- Details from  Thomas Schatzl -----

Main testing should be in the area of 
a) not breaking existing functionality - the feature is completely
transparent to the VM and
b) memory usage reductions.

What the feature does:
- uncommits parts of the Java heap and auxiliary data according to the
current sizing policy (e.g. HeapMin/MaxFreeRatio) at full GCs.

Full GCs are the only point in time where the heap is decreased.

The release (uncommit) of this data is based on regions. I.e. the unit
of memory freeing is regions, when a region is freed, all its associated
auxiliary data should go away as required.

There is one complication in this matter, and that is that the unit of
commit/uncommit is always OS memory pages, but an OS page worth of
auxiliary data may cover multiple regions. If one of these regions is
still not uncommitted, the auxiliary data cannot be freed either.

This ratio between OS memory page size and region size is not fixed too,
both OS memory page size and region size can vary depending on flags
(UseLargePages etc).

The change is G1 only too.

So, what are the relevant memory consumers:
 - Java heap: split into disjoint regions, given G1RegionSize (range 1M
to 32M, power of two increments); can be managed either with "OS page
size" or large pages (-XX:+UseLargePages active).

 - Auxiliary data:
   contents of auxiliary data always map directly to a disjoint
contiguous section of the Java heap. Their memory is *always* managed in
native page size.

   - Two mark bitmaps, where each bit maps to an area of
MinObjAlignmentInBytes * BitsPerByte bits.
MinObjAlignmentInBytes can vary from 8 (default) to 256 iirc (actually I
cannot find a bound, but it must be a power of two).

This amounts to ~3% of heap space by default; if 4k pages are used (e.g.
on x86), a single page spans 256k of heap (i.e. only a fraction of a
region in any case) - but with increasing MinObjAlignmentInBytes a
single page may span multiple regions.

  - Three "tables" (card table, offset table, hot card cache count)
where in each element of them spans an area of 512 bytes. This is
hardcoded at this time.

The hot card cache count table is only used if it is enabled
(G1ConcRSLogCacheSize is larger than zero).

E.g. with 4k pages, each of them span 2 MB of heap.

In total they make up 0.6% of the Java heap.

Current status:
- there is a prototype available (for creating tests) that manages the
Java heap, the mark bitmaps, and one of the mentioned tables.

So I think you can already start working on tests.

Planned date that this feature to be finished and in the repos is 9th of
June. It may be delayed slightly because we did not plan my vacation (I
talked to Paul about this already) into that time.

I will start getting reviews for the first changes next week.

Difficulties I see here:
- getting reliable information of actual uncommitted memory. I.e. it is
not only important that the VM reports that the heap shrank, but actual
memory usage (e.g. RSS size or whatever) adjusted correctly (i.e. that
the commit/uncommit calls are made correctly).
Also somehow the amount of memory committed/uncommitted what the VM
thinks should probably be checked.

- there is a fairly large amount of possible combinations of settings
that should be checked.

- getting the VM to reliably uncommit a particular area. Possibly best
achievable using large object allocations.