[RFR] 8043766: CMM Testing: 8u40 Decommit auxiliary data structures

[Thomas Schatzl]

Hi Andrey,

On Thu, 2014-09-25 at 20:28 +0400, Andrey Zakharov wrote:
> BTW, tested in aurora with latest jdk 8 updates
> 593423.ute.hs_jtreg.accept.full

Some questions:

- the different tests seem to be only different in the number of
iterations the allocate/link/mutate/deallocate cycle runs. They all use
the same G1ConcRSLogCacheSize, but vary object alignment.

That seems okay, but why is there need to run for different amount of
time, particularly so many?

Earlier versions of the test varied G1ConcRSLogCacheSize and object
alignment, and did only a single iteration always. Not sure if simply
testing G1ConcRSLogCacheSize for a few important values (0, 10, 15,
maybe not even the last because the only difference in code is for 0 and
something) and a single fixed length (not necessarily a single
iteration) would achieve the same job?

G1ConcRSLogCacheSize of 10 does not require that much memory (and in
fact is default) so that you need to worry about its maximum size.

- fixing G1ConcRSLogCacheSize would also remove the need to calculate
some maximum value for G1ConcRSLogCacheSize. GetMaxCacheSize()
calculates the maximum G1ConcRSLogCacheSize based on the free java heap.
However, the data structure is allocated on the C heap, there is no real
connection between free java heap and free C heap anyway.

Thanks,
  Thomas