RFR: 8255234: ZGC: Bulk allocate forwarding data structures

[Albert Mingkun Yang]

On Thu, 22 Oct 2020 12:02:19 GMT, Per Liden <pliden at openjdk.org> wrote:

> Allocation of forwarding data structures (ZForwarding/ZForwardingEntry instances) can generate a lot of calls to new/malloc if the number of pages in the relocation set is large. This can make the "Concurrent Select Relocation Set" phase long. By bulk allocating a single piece of memory and then placement new() all objects into that memory we can speed this phase up quite a bit.
> 
> During relocation set selection we keep track of the number of ZForwardingEntry instances we will need for the selected relocation set. The ZForwardingAllocator is then initialized to have enough room for all the relocation set array, all ZForwarding instances, and all ZForwardingEntry instances. Objects are then placement new()'d using into the memory allocated by the ZForwardingAllocator.
> 
> This patch was joint work with Albert (ayang).

Changes requested by ayang (Author).

src/hotspot/share/gc/z/zRelocationSet.cpp line 70:

> 68: 
> 69: void ZRelocationSet::reset() {
> 70:   _nforwardings = 0;

This is not needed, right? `_nforwardings` will be properly reset in `populate`.

src/hotspot/share/gc/z/zForwardingAllocator.inline.hpp line 38:

> 36:     // Not enough space left
> 37:     return NULL;
> 38:   }

This allocator should never return null; better use assert.

src/hotspot/share/gc/z/zRelocationSet.cpp line 66:

> 64: 
> 65:   // Update statistics
> 66:   ZStatRelocation::set_at_populate_relocation_set(_allocator.size());

Instead of `_allocator.size()`, one could use the same arg of `_allocator.reset()`, which is already known in this scope.

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

PR: https://git.openjdk.java.net/jdk/pull/804