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

[Vladimir Kozlov]

I think the suggestion is reasonable since we increase CodeCache *5 for Tiered.
Albert, is it possible to collect data how much space is wasted in % before and after this change: free space in which 
we can't allocate + unused bytes at the end of nmethods/adapters? Can we squeeze an adapter into 64 bytes?

Thanks,
Vladimir

On 2/4/14 7:41 AM, Albert wrote:
> 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
>