RFR(M): 8198756: Lazy allocation of compiler threads
Doerr, Martin
martin.doerr at sap.com
Fri Mar 23 15:04:11 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180323/d16e9523/attachment.html>
More information about the hotspot-compiler-dev
mailing list