[9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.
dean long
dean.long at oracle.com
Fri Oct 10 04:41:09 UTC 2014
Hi Albert,
256 {
257 ThreadBlockInVM tbivm(JavaThread::current());
258 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag);
259 const long wait_time = 60*60*24 * 1000;
260 timeout = CodeCache_lock->wait(Mutex::_no_safepoint_check_flag, wait_time);
261 }
262 // We need to check for the safepoint to be able to exit the VM
263 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag);
264 NMethodSweeper::handle_safepoint_request();
How about simplifying the above so that you don't release and then
reacquire the lock:
256 {
257 ThreadBlockInVM tbivm(JavaThread::current());
258 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag);
259 const long wait_time = 60*60*24 * 1000;
260 timeout = CodeCache_lock->wait(Mutex::_no_safepoint_check_flag, wait_time);
261 // We need to check for the safepoint to be able to exit the VM
262 NMethodSweeper::handle_safepoint_request();
263 }
(This is not a full review, just a comment.)
dl
On 10/9/2014 1:24 AM, Albert Noll wrote:
> Hi,
>
> could I get reviews for this patch?
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8046809
>
> Problem:
> 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.
>
> Solution:
> 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
> NmethodSweepCheckInterval
> 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
> compilation.
>
> 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() <
> CodeCacheMinimumFreeSpace:
>
> segments_to_size(number_of_segments) > (heap_unallocated_capacity() -
> CodeCacheMinimumFreeSpace)
>
> 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.
>
> Correctness testing:
> Failing test case, JPRT
>
> Performance testing:
> The bug contains a link to performance results.
>
> Webrev:
> http://cr.openjdk.java.net/~anoll/8046809/webrev.02/
>
> Many thanks in advance,
> Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141009/dbc69f09/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list