RFR: 8343205: CompileBroker::possibly_add_compiler_threads excessively polls available memory

Vladimir Kozlov kvn at openjdk.org
Thu Oct 31 17:49:32 UTC 2024


On Thu, 31 Oct 2024 17:03:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This PR adds a quick check + bail out in order to avoid excessive usage of slow checks. Especially, it avoids querying the available memory so often.

src/hotspot/share/compiler/compileBroker.cpp line 1027:

> 1025: 
> 1026:   int old_c2_count = 0, new_c2_count = 0, old_c1_count = 0, new_c1_count = 0;
> 1027:   const int c2_tasks_per_thread = 2, c1_tasks_per_thread = 4;

Any reason to have such numbers (2 and 4)?  Any experiments were done to select the best numbers?

src/hotspot/share/compiler/compileBroker.cpp line 1029:

> 1027:   const int c2_tasks_per_thread = 2, c1_tasks_per_thread = 4;
> 1028: 
> 1029:   // Do a quick check first without taking the lock. The later ones are more expensive.

Please, expend comment to explain what check is done here.

src/hotspot/share/compiler/compileBroker.cpp line 1031:

> 1029:   // Do a quick check first without taking the lock. The later ones are more expensive.
> 1030:   if (_c2_compile_queue != nullptr) {
> 1031:     old_c2_count = _compilers[1]->num_compiler_threads();

Can you use accessors here `get_c1_thread_count()` and `get_c2_thread_count()` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21812#discussion_r1824907203
PR Review Comment: https://git.openjdk.org/jdk/pull/21812#discussion_r1824900534
PR Review Comment: https://git.openjdk.org/jdk/pull/21812#discussion_r1824899251


More information about the hotspot-compiler-dev mailing list