RFR(M): 8211424: Allocation of old generation of java heap on alternate memory devices - ParallelOld

Stefan Johansson stefan.johansson at oracle.com
Fri Nov 30 14:11:44 UTC 2018


Hi Kishor,

On 2018-11-22 08:17, Kharbas, Kishor wrote:
> Hi all,
> 
> Requesting review of the patch for allocating old generation of 
> parallelold gc on alternate memory devices such nv-dimm.
> 
> The design of this implementation is explained on the bug page - 
> https://bugs.openjdk.java.net/browse/JDK-8211424.
> 
> This is subtask of https://bugs.openjdk.java.net/browse/JDK-8202286 
> which is implementation for parallel old gc.
> 
> Please follow the parent issue here :   64   if (AllocateOldGenAt != NULL && UseAdaptiveGCBoundary) {
   65     heap_size = 
AdjoiningGenerationsForHeteroHeap::required_reserved_memory(_collector_policy);
   66   }
> https://bugs.openjdk.java.net/browse/JDK-8202286.
> 
> (PS: this is continuation of old thread 'RFR(M): 8204908: NVDIMM for 
> POGC and G1GC - ReserveSpace.cpp changes are mostly eliminated/no 
> collector specific code.’)
> 
> Webrev: http://cr.openjdk.java.net/~kkharbas/8211424/webrev.04

First a general comment which goes a long the same lines as many of my 
comments for the G1 part. I would like to see some more abstraction 
around the use of AllocateOldGenAt, I think we should consider it during 
argument parsing to turn off unsupported things like compressed oops and 
once during initialization of the GC to know if we are using the feature 
or not. After that there should only be calls like 
policy->is_hetero_heap() if we really need to decide on this.

src/hotspot/share/gc/parallel/adjoiningGenerations.cpp
------------------------------------------------------
97 
virtual_spaces()->reserved_space().first_part(max_low_byte_size, 
AllocateOldGenAt != NULL /* split */);
   One example of what I mention above, I think you should consider 
doing the same as you did for G1 and create the ParallelScavengeHeap 
with at CollectorPolicy that is nvdimm aware.

src/hotspot/share/gc/parallel/asPSOldGen.hpp
--------------------------------------------
   32 #include "gc/parallel/psFileBackedVirtualspace.hpp"

I see no use of this in this header.

src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
------------------------------------------------------
   65   // is the heap backed by two different memories?
   66   bool _is_hetero_heap;

As for G1 I think this doesn't need to be stored in the heap but the 
CollectorPolicy (GenerationSizer) knows this and can be queried when 
needed. Keeping the getter is fine, but just have it call the policy.

src/hotspot/share/gc/parallel/psOldGen.cpp
------------------------------------------
   75   if(AllocateOldGenAt != NULL) {
   76     _virtual_space = new PSFileBackedVirtualSpace(rs, alignment, 
AllocateOldGenAt);
   77     if (!(static_cast 
<PSFileBackedVirtualSpace*>(_virtual_space))->initialize()) {
   78       vm_exit_during_initialization("Could not map space for 
PSOldGen at given AllocateOldGenAt path");
   79     }

Either pass in if this is a hetero heap or ask the heap, it can be 
obtained by ParallelScavengeHeap::heap().

I also think it would be better to have the PSFileBackedVirtualSpace 
constructor call initialize directly and let it fail rather than 
returning false, since we will abort the VM in this case anyway.

src/hotspot/share/memory/universe.cpp
-------------------------------------
  829   // When AllocateOldGenAt is set, we cannot use largepages for 
entire heap memory.
  830   // Only young gen which is allocated in dram can use large 
pages, but we currently don't support that.
  831   use_large_pages = (AllocateOldGenAt != NULL) ? false : 
use_large_pages;

Move this to argument parsing and do FLAG_SET_DEFAULT(UseLargePages, 
false) when nvdimm is used.

src/hotspot/share/runtime/arguments.cpp
---------------------------------------
1627   if(AllocateOldGenAt != NULL) {
1628     FLAG_SET_ERGO(bool, UseCompressedOops, false);
1629     return;
1630   }

As for G1 I can't see no reason why this can't be moved to 
GCArguments::init.

Thanks,
Stefan

> 
>                  
> http://cr.openjdk.java.net/~kkharbas/8211424/webrev.03_to_04
> 
> Thanks
> 
> Kishor
> 


More information about the hotspot-gc-dev mailing list