RFR(M): 8198756: Lazy allocation of compiler threads

[Vladimir Kozlov]

Very cool!

Few thoughts.

You can't delete thread when it is NULL (missing check or refactor code):

    if (thread == NULL || thread->osthread() == NULL) {
+    if (UseDynamicNumberOfCompilerThreads && comp->num_compiler_threads() > 0) {
+      delete thread;

Why not keep handle instead of returning naked oop from create_thread_oop()? You create Handle again

Start fields names with _ to distinguish them from local variable:

+  static int c1_count, c2_count;

In possibly_add_compiler_threads() you can use c2_count instead of calling compile_count() again and array size is fixed 
already:

+    int new_c2_count = MIN3(_c2_compile_queue->size() / 2,
+        CompilationPolicy::policy()->compiler_count(CompLevel_full_optimization),

And I thought we would need to add only one threads each time when we hit some queue size threshold. At the start queues 
filled up very fast so you may end up creating all compiler threads. Or we may need more complex formula.

We may need to free corresponding java thread object when we remove compiler threads.

Thanks,
Vladimir

On 3/23/18 8:04 AM, Doerr, Martin wrote:
> Hi Vladimir,
> 
> thanks for updating the RFE. I already had similar ideas so I've implemented a prototype.
> 
> I'll be glad if you can support this effort.
> 
> My implementation starts only one thread per type (C1/C2) initially. Compiler threads start additional threads depending 
> on the compile queue size, the available memory and the predetermined maximum. The Java Thread objects get created 
> during startup so the Compiler Threads don't need to call Java.
> 
> The heuristics (in possibly_add_compiler_threads()) are just an initial proposal and we may want to add tuning 
> parameters or different numbers.
> 
> Threads get stopped in reverse order as they were created when their compile queue is empty for some time.
> 
> The feature can be switched by -XX:+/-UseDynamicNumberOfCompilerThreads. Thread creating and removal can be traced by 
> -XX:+TraceCompilerThreads.
> 
> Webrev is here:
> 
> http://cr.openjdk.java.net/~mdoerr/8198756_CompilerCount/webrev.01/
> 
> The following issues need to get addressed, yet:
> 
> -Test JVMCI support. (I'm not familiar with it.)
> 
> -Possible memory leaks. I've added some delete calls when a thread dies, but they may be incomplete.
> 
> -Logging.
> 
> -Performance and memory consumption evaluation.
> 
> It would be great to get support and advice for these issues.
> 
> Best regards,
> 
> Martin
>