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

[Albert]

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/f49c6b0e/attachment.html>