[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