RFR: 8237198+8237199+8237200: ZGC: Share heap multi-mapping code across platforms

Per Liden per.liden at oracle.com
Thu Jan 16 10:50:12 UTC 2020


Thanks Stefan!

/Per

On 1/16/20 11:13 AM, Stefan Karlsson wrote:
> Looks good.
> 
> StefanK
> 
> On 2020-01-15 13:57, Per Liden wrote:
>> Hi,
>>
>> Please review this cleanup of the ZPhysicalMemory/ZBackingFile layer, 
>> which aims to de-duplicate some of the multi-mapping code. I've split 
>> the change into three separate patches, the main patch followed by two 
>> patches doing some renaming.
>>
>>
>> 1) The ZBackingFile code was designed to allow platforms to decide if 
>> they want to use heap multi-mapping or some other (possibly HW 
>> supported) scheme. As of today, all our supported platforms do heap 
>> multi-mapping, so there's some degree of code duplication in 
>> ZBackingFile for each platform. This patch moves common multi-mapping 
>> code into ZPhysicalMemoryManager. If we in the future find that we 
>> want to support a platform that doesn't do multi-mapping, then we can 
>> introduce an abstraction for this again.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237198
>> Webrev: http://cr.openjdk.java.net/~pliden/8237198/webrev.0
>>
>>
>> 2) Rename ZBackingFile to ZPhysicalMemoryBacking, since "File" is 
>> somewhat misleading on platforms other than Linux.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237199
>> Webrev: http://cr.openjdk.java.net/~pliden/8237199/webrev.0
>>
>>
>> 3) Rename ZBackingPath to ZMountPoint, as it's a better name in light 
>> of JDK-8237199.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237200
>> Webrev: http://cr.openjdk.java.net/~pliden/8237200/webrev.0
>>
>>
>> cheers,
>> Per


More information about the hotspot-gc-dev mailing list