[9] RFR(S): JDK-8040798: compiler/startup/SmallCodeCacheStartup.java timed out in RT_Baseline

[Igor Veresov]

Wouldn’t the recovery be faster if we do task->lock()->notify() in the task deletion loop in CompileQueue::delete_all() to wake up all the threads that are waiting for the compilation to complete instead of having to wait with a timeout?

igor

On Apr 22, 2014, at 6:42 AM, Albert <albert.noll at oracle.com> wrote:

> Hi,
> 
> could I get reviews for this small change?
> 
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-8040798
> 
> Problem:
> The test starts the JVM with 3m code cache and 64 compiler threads. As a result, it is very likely 
> that not all compiler threads can be started due to insufficient space in the code cache. It is also 
> possible that the compiler runtime initialization of C1 and/or C2 fails. There is a race between a
> the blocking compilations (the test is started with -Xcomp) and the process of shutting down the 
> compilers. More specifically, it can happen that (1) a blocking compilation task is put into a compilation
> queue, (2) the compilers are shut down, and (3) the application thread waits forever until the compilation 
> completes (The compilation will never complete, since all compiler threads are exited).
> 
> Solution:
> Add a timeout to the wait() that waits for a compilation to complete and check if compilation is shut down
> forever. Furthermore, if we shut down the compiler runtimes, make sure that we use the interpreter to 
> continue execution. The changes that fix the bug are in the following functions:
> 
> CompileBroker::wait_for_completion(CompileTask* task)
> shutdown_compiler_runtime(AbstractCompiler* comp, CompilerThread* thread)
> 
> The patch also removes the destruction of the compile queue objects in shutdown_compiler_runtime(). 
> The destruction is removed, since it does not reclaim significant portions of memory, but possible introduces 
> problems, since pointers to the compile queues can be used at other locations in the code. An assert ensures 
> that no more tasks are put into a compilation queue once the compilers have been shut down.
> 
> In addition, the patch adds two locks in:
> void CompileBroker::mark_on_stack()
> 
> The two locks ensure that compilation tasks are not removed from the compilation queue or freed by a 
> different (compiler) thread while the method mark_on_stack is executed. I am not really sure if that lock
> is needed. However, the lock seems to prevent concurrent read/writes of the compilation queue.
> 
> The rest of the changes are simple optional refactorings.
> 
> Testing:
> The timeout does not occur with the proposed changes. JPRT.
> 
> Webrev:
> http://cr.openjdk.java.net/~anoll/8040798/webrev.00/
> 
> Many thanks in advance,
> Albert
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140422/fe829ce6/attachment-0001.html>