JDK-8244065 : Implement NUMA support on Windows
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-04-29
  • Updated: 2023-09-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8316886 - Remove redundant range check in NUMANodeListHolder::get_node_list_entry
Relates :  
JDK-8240654 - Windows GDI functions can fail and cause severe UI application repaint issues
Relates :  
JDK-8046153 - JEP 163: Enable NUMA Mode by Default When Appropriate
Relates :  
JDK-8243628 - Deprecate -XX:ForceNUMA option
Description
The os:: layer for NUMA support provided by -XX:+UseNUMA consists of stubs on Windows. UseNUMA is forced off in os::init_2 unless ForceNUMA is also true.
Comments
UseNUMAInterleaving works, but is done manually using VirtualAllocExNuma during reservation. The difference to other OSes is that on Windows, the preferred node seems to be required to be specified on memory reservation, not by giving a hint anytime before commit. This seems to be why os::make_numa_local() is a stub on Windows. One way to implement G1 and Parallel GC support may be to do per-region or per-space reservations with the (later) required node id. There may be further limitations (or simply me misunderstanding the code) that prevent this.
29-04-2020