[9] RFR(M): 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000

[Albert]

Hi,

could I get reviews for this patch (nightly failure)?

webrev: http://cr.openjdk.java.net/~anoll/8029799/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8029799

problem: The freelist of the code cache exceeds 10'000 items, which 
results in a VM warning.
                 The problem behind the warning is that the freelist is 
populated by a large number
                 of small free blocks. For example, in failing test case 
(see header), the freelist grows
                 up to more than 3500 items where the largest item on 
the list is 9 segments (one segment
                 is 64 bytes). That experiment was done on my laptop. 
Such a large freelist can indeed be
                 a performance problem, since we use a linear search to 
traverse the freelist.
solution:  One way to solve the problem is to increase the minimal 
allocation size in the code cache.
                 This can be done by two means: we can increase 
CodeCacheMinBlockLength and/or
                 CodeCacheSegmentSize. This patch follows the latter 
approach, since increasing
                 CodeCacheSegmentSize decreases the size that is 
required by the segment map. More
                 concretely, the patch doubles the CodeCacheSegmentSize 
from 64 byte to 128 bytes
                 if tiered compilation is enabled.
                 The patch also contains an optimization in the freelist 
search (stop searching if we found
                 the appropriate size) and contains some code cleanups.
testing:    With the proposed change, the size of the freelist is 
reduced to 200 items. There is only
                 a slight increase in memory required by code cache by 
at most 3% (all data measured
                 for the failing test case on a Linux 64-bit system, 4 
cores).
                 To summarize, increasing the minimum allocation size in 
the code cache results in
                 potentially more unused memory in the code cache due to 
unused bits at the end of
                 an nmethod. The advantage is that we potentially have 
less fragmentation.

proposal: - I think we could remove CodeCacheMinBlockLength without loss 
of generality or usability
                   and instead adapt the parameter CodeCacheSegmentSize 
at Vm startup.
                   Any opinions?

Many thanks in advance,
Albert