RFR(S) 8233093: Move CDS heap oopmaps into new MetaspaceShared::bm region

[Ioi Lam]

Hi Calvin,

Looks good. Just some minor nits for filemap.cpp:

1244   if (closed_oopmaps != NULL && open_oopmaps != NULL) {
1245     size_t curr_offset = write_oopmaps(closed_oopmaps, 
ptrmap->size_in_bytes(), buffer);
1246     curr_offset = write_oopmaps(open_oopmaps, curr_offset, buffer);

There's no need to write to curr_offset on line 1246.

----

Unnecessary new line at 1897.

----

1599     current_info()->unmap_region(MetaspaceShared::bm);

This call can be removed, because the "bm" region will be eventually 
unmapped by the new code in MetaspaceShared::initialize_shared_spaces(). 
This way, if we later need to relocate the archived heap relocation, 
there's no need to map the "bm" region again.

Thanks
- Ioi


On 3/25/20 9:39 AM, Calvin Cheung wrote:
> RFE: https://bugs.openjdk.java.net/browse/JDK-8233093
>
> webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8233093/webrev.00/
>
> The MetaspaceShared::bm region was introduced via JDK-8231610 
> (Relocate the CDS archive if it cannot be mapped to the requested 
> address) and only used during archive loading. The region will be 
> unmapped afterwards to save memory footprint. Since the heap oopmaps 
> are also only used during archive loading, it makes sense for them to 
> reside in the "bm" region as well.
>
> Before:
> [0.753s][debug][cds] ro space: 7552120 [ 59.7% of total] out of 
> 7553024 bytes [100.0% used] at 0x00000008003e1000
> [0.753s][debug][cds] bm space: 184320 [ 1.5% of total] out of 184320 
> bytes [100.0% used] at 0x0000000000000000
>
> After:
> [0.766s][debug][cds] ro space: 7525856 [ 59.5% of total] out of 
> 7528448 bytes [100.0% used] at 0x00000008003e1000
> [0.766s][debug][cds] bm space: 208896 [ 1.7% of total] out of 208896 
> bytes [100.0% used] at 0x0000000000000000
>
> Passed tiers 1 - 4 testing.
>
> thanks,
>
> Calvin
>