RFR(M): 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000
vladimir.kozlov at oracle.com
Tue Feb 4 08:52:24 PST 2014
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?
On 2/4/14 7:41 AM, Albert wrote:
> 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,
More information about the hotspot-compiler-dev