Some debuggers don't work well with many threads, and/or incompletely restricts the number of used CPUs to one.
This flag is intended as a catch-all for HotSpot developers (not available in product builds) to allow us to more easily use those debuggers.
Currently, the proposal is to let the flag fix a few things:
1) Turn down the number of JVM threads
2) Turn off NUMA
3) Force processor_id() to return 0 instead of values above processor_count()
(1) is purely ergonomics: gdb, rr, valgrind is faster and seems to work much better with fewer threads. The values would still be overridable by devs.
(2) and (3) deals with the fact that some debuggers change the reported processor count, but don't change the processor ids returned by sched_getcpu. This causes problems for ZGC and NUMA, that both assumes that they can rely on os::processor_id() < os::processor_count().
The current proposed flag name is -XX:+LimitedCPUsDebugging. I'm not entirely happy with that name, but I been able to find a better name.
An alternative to having one flag, is to split this into two flags, and maybe that would solve the naming problem. However, the usability aspects will be worse.
If we can't find a suitable name, I rather introduce a flag called:
-XX:DebuggerWorkarounds or -XX:DebuggerWorkaround1
This flag is intended as a catch-all for HotSpot developers (not available in product builds) to allow us to more easily use those debuggers.
Currently, the proposal is to let the flag fix a few things:
1) Turn down the number of JVM threads
2) Turn off NUMA
3) Force processor_id() to return 0 instead of values above processor_count()
(1) is purely ergonomics: gdb, rr, valgrind is faster and seems to work much better with fewer threads. The values would still be overridable by devs.
(2) and (3) deals with the fact that some debuggers change the reported processor count, but don't change the processor ids returned by sched_getcpu. This causes problems for ZGC and NUMA, that both assumes that they can rely on os::processor_id() < os::processor_count().
The current proposed flag name is -XX:+LimitedCPUsDebugging. I'm not entirely happy with that name, but I been able to find a better name.
An alternative to having one flag, is to split this into two flags, and maybe that would solve the naming problem. However, the usability aspects will be worse.
If we can't find a suitable name, I rather introduce a flag called:
-XX:DebuggerWorkarounds or -XX:DebuggerWorkaround1