[9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.

[Albert Noll]

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/574d30cd/attachment-0001.html>