RFR(M): 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000
albert.noll at oracle.com
Wed Feb 5 08:28:47 PST 2014
thanks for looking at this. I've done the proposed measurements. The
code which I used to
get the data is included in the following webrev:
I think some people might be interested in getting that data, so we
might want to keep
that additional output. The exact output format can be changed later
Here are the results:
- failing test case:
- original: allocated in freelist: 2168kB, unused bytes in CodeBlob:
818kB, max_used: 21983kB
- patch : alloacted in freelist: 1123kB, unused bytes in CodeBlob:
2188kB, max_used: 17572kB
- original : allocated in freelist: 2426kB, unused bytes in CodeBlob:
1769kB, max_used: 201886kB
- patch : allocated in freelist: 1150kB, unused bytes in CodeBlob:
3458kB, max_used: 202394kB
- SPECJVM2008: compiler.compiler:
- original : allocated in freelist: 168kB, unused bytes in
CodeBlob: 342kB, max_used: 19837kB
- patch : allocated in freelist: 873kB, unused bytes in
CodeBlob: 671kB, max_used: 21184kB
The minimum size that can be allocated from the code cache is
I.e., the minimum size depends on CodeCacheSegmentSize and
On x86, for example, the min. allocatable size from the code cache is
The size of adapters ranges from 400b to 600b.
Here is the beginning of the nmethod size distribution of the failing
nmethod size distribution (non-zombie java)
0-16 bytes 0[bytes]
16-32 bytes 0
32-48 bytes 45
48-64 bytes 0
64-80 bytes 41
80-96 bytes 0
96-112 bytes 6247
112-128 bytes 0
128-144 bytes 249
144-160 bytes 0
160-176 bytes 139
176-192 bytes 0
192-208 bytes 177
208-224 bytes 0
224-240 bytes 180
240-256 bytes 0
I do not see a problem for increasing the CodeCacheSegmentSize if tiered
What do you think?
On 02/04/2014 05:52 PM, Vladimir Kozlov wrote:
> 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