RFR: 8237198+8237199+8237200: ZGC: Share heap multi-mapping code across platforms
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
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
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
Looks good to me, thanks. Stuart On Wed, 15 Jan 2020 at 12:57, Per Liden <per.liden@oracle.com> 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
Thanks for reviewing, Stuart! cheers, Per On 1/16/20 2:24 PM, Stuart Monteith wrote:
Looks good to me, thanks.
Stuart
On Wed, 15 Jan 2020 at 12:57, Per Liden <per.liden@oracle.com> 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
Hi Per, I like the red stuff. +1 /Erik On 1/15/20 1:57 PM, 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
Thanks Erik! /Per On 1/16/20 3:44 PM, erik.osterlund@oracle.com wrote:
Hi Per,
I like the red stuff. +1
/Erik
On 1/15/20 1:57 PM, 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
participants (4)
-
erik.osterlund＠oracle.com
-
Per Liden
-
Stefan Karlsson
-
Stuart Monteith