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