RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.
vladimir.kozlov at oracle.com
Thu Oct 9 17:43:14 UTC 2014
On 10/9/14 1:24 AM, Albert Noll wrote:
> 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.
There is flag GuaranteedSafepointInterval. The corresponding code in
VMThread::loop() is guarded by
SafepointSynchronize::is_cleanup_needed(). You may add additional
> 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.
Can you do CodeCacheMinimumFreeSpace and 'critical' code removal in a
separate changes? Current changes are big enough already.
> Correctness testing:
> Failing test case, JPRT
> Performance testing:
> The bug contains a link to performance results.
> Many thanks in advance,
More information about the hotspot-compiler-dev