RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.
albert.noll at oracle.com
Thu Oct 9 08:24:58 UTC 2014
could I get reviews for this patch?
The test generates an artificially large number of adapters.
CodeCacheMinimumFreeSpace in not large enough to hold all adapters,
if the code cache gets full. Furthermore, the JVM is in a state where no
safepoint is requested. As a result, stack scanning of active
methods does not happen and consequently nmethods cannot be flushed from
the code cache.
The following two changes fix the problem:
1) Introduce a new VM operation that forces stack scanning of active methods
In the current design, the code cache sweeper can only make progress
(i.e., remove compiled code) if
safepoints are triggered. More specifically, several safepoints must
occur to concert compiled code from
state 'not_entrant' to 'unloaded'. If no safepoints are triggered, code
cannot be removed from the code
cache. If the code cache fills up and safepoints are triggered too
infrequently, the sweeper cannot remove
compiled code from the code cache fast enough.
This patch forces a VM operation to do stack scanning, if there is 10%
free space in the code cache. Is parameter
is currently constant. I command line parameter can be added to provide
the user with explicit control over this
threshold. I think we can add such a command line parameter on demand.
2) Use a dedicated sweeper thread that processes the whole code cache at
once (remove NmethodSweepFraction)
Using a separate sweeper thread comes at the cost requiring more memory
(mostly the stack size of the sweeper
thread) but has numerous benefits:
a) Code gets simpler: We can remove NMethodSweepFraction and
b) More aggressive sweeping: If the code cache gets full, we can process
the entire code
cache without taking away cycles that are potentially needed for
The patch also removes CodeCacheMinimumFreeSpace and 'critical' code
cache allocations. Due to a bug in
heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for
'critical' allocations. The following
lines produce an underflow if heap_unallocated_capacity() <
segments_to_size(number_of_segments) > (heap_unallocated_capacity() -
Since the critical part in the code cache was never used for its
intended purpose and we did not have problems
due to that, we can remove it.
Failing test case, JPRT
The bug contains a link to performance results.
Many thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev