-
Type:
Enhancement
-
Resolution: Won't Fix
-
Priority:
P4
-
Affects Version/s: None
-
Component/s: hotspot
The current allocation policy for new objects (or TLABs) when NUMA is enabled, is the following:
1. Try to allocate on the local LGRP space in MutableNUMASpace
2. If not a TLAB allocation, try to allocate in the Old gen
3. In extreme cases, try to allocate in the from-space
It is possible to extend the allocation policy when NUMA is enabled to also try to allocate on remote LGRP space(s). This opens ups the allocation space from one LGRP space to multiple. The effect of this is that Thread(s) no longer need to keep track of their assigned LGRP id, as well as expanding the tlab accounting/statistics from one space to all spaces.
Additionally, Parallel's MutableNUMASpace is the only garbage collector interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used and unsafe_max_tlab_alloc. Removing the need for the thread via this proposal makes it possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs.
In this proposal, the new allocation policy looks like:
1. Try to allocate on the local LGRP space in MutableNUMASpace
2. Try to allocate on any remote LGRP space in MutableNUMASpace
3. If not a TLAB allocation, try to allocate in the Old gen
4. In extreme cases, try to allocate in the from-space
Some considerations: When allocating objects in remote LGRP spaces, this likely lowers the successrate of allocations that are local to those spaces in the future, which might lower performance. However, opening up the allocation space to more memory, which is the effect this proposal has, might result in fewer allocation-triggered garbage collections, which might increase performance instead.
1. Try to allocate on the local LGRP space in MutableNUMASpace
2. If not a TLAB allocation, try to allocate in the Old gen
3. In extreme cases, try to allocate in the from-space
It is possible to extend the allocation policy when NUMA is enabled to also try to allocate on remote LGRP space(s). This opens ups the allocation space from one LGRP space to multiple. The effect of this is that Thread(s) no longer need to keep track of their assigned LGRP id, as well as expanding the tlab accounting/statistics from one space to all spaces.
Additionally, Parallel's MutableNUMASpace is the only garbage collector interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used and unsafe_max_tlab_alloc. Removing the need for the thread via this proposal makes it possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs.
In this proposal, the new allocation policy looks like:
1. Try to allocate on the local LGRP space in MutableNUMASpace
2. Try to allocate on any remote LGRP space in MutableNUMASpace
3. If not a TLAB allocation, try to allocate in the Old gen
4. In extreme cases, try to allocate in the from-space
Some considerations: When allocating objects in remote LGRP spaces, this likely lowers the successrate of allocations that are local to those spaces in the future, which might lower performance. However, opening up the allocation space to more memory, which is the effect this proposal has, might result in fewer allocation-triggered garbage collections, which might increase performance instead.