Re: CFV: New Project: ZGC

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Stefan Karlsson
Vote: YES

StefanK

On 2017-10-25 21:45, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will
> provide a home for the continued development of the Z Garbage
> Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally
> at Oracle so far, and we're now open-sourcing it so as to broaden the
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of
> relevant workloads. At the same time we want to acknowledge that we
> don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World
> phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java
> thread's perspective, the act of loading a reference field in a Java
> object is subject to a load barrier. In addition to an object address,
> a colored object pointer contains information used by the load barrier
> to determine if some action needs to be taken before allowing a Java
> thread to use the pointer. For example, the object might have been
> relocated, in which case the load barrier will detect the situation
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This
> helps keep the runtime overhead down. It also means that it's easier
> to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows
> us to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in
> non-GC subsystems in HotSpot, such as being able to concurrently
> unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote


Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

coleen.phillimore
Vote: yes

On 10/25/17 3:45 PM, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will
> provide a home for the continued development of the Z Garbage
> Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally
> at Oracle so far, and we're now open-sourcing it so as to broaden the
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of
> relevant workloads. At the same time we want to acknowledge that we
> don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World
> phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java
> thread's perspective, the act of loading a reference field in a Java
> object is subject to a load barrier. In addition to an object address,
> a colored object pointer contains information used by the load barrier
> to determine if some action needs to be taken before allowing a Java
> thread to use the pointer. For example, the object might have been
> relocated, in which case the load barrier will detect the situation
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This
> helps keep the runtime overhead down. It also means that it's easier
> to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows
> us to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in
> non-GC subsystems in HotSpot, such as being able to concurrently
> unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

John Rose-3
In reply to this post by Stefan Karlsson
Vote: yes!

On Oct 25, 2017, at 12:45 PM, Per Liden <[hidden email]> wrote:
>
> I hereby propose the creation of the ZGC Project with myself (Per Liden) as the Lead and the HotSpot Group as the sponsoring Group.

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Thomas Schatzl
In reply to this post by Stefan Karlsson
Vote: yes

Thomas

> On 2017-10-25 21:45, Per Liden wrote:
> > I hereby propose the creation of the ZGC Project with myself (Per 
> > Liden) as the Lead and the HotSpot Group as the sponsoring Group.
> >
> > In accordance with the OpenJDK guidelines [1], this project will 
> > provide a home for the continued development of the Z Garbage 
> > Collector, also known as ZGC. ZGC is a new garbage collector
> > optimized for low latency and very large heaps. We've developed ZGC
> > internally at Oracle so far, and we're now open-sourcing it so as
> > to broaden the base of both contributors and users.
> >
> > ZGC has been designed with the following goals in mind:
> > * Handle multi-terabyte heaps
> > * GC pause times not exceeding 10ms
> > * No more than 15% application throughput reduction compared to
> > using G1

:)
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Vladimir Kozlov
In reply to this post by Stefan Karlsson
Vote: yes

On 10/25/17 12:45 PM, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will provide a home for the continued development of the Z Garbage Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally at Oracle so far, and we're now open-sourcing it so as to broaden the base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of relevant workloads. At the same time we want to acknowledge that we don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation, region-based, incrementally compacting collector. Stop-The-World phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is reasonably mature and stable. ZGC today executes the following GC tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in combination with colored object pointers (i.e. colored oops). This is what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java thread's perspective, the act of loading a reference field in a Java object is subject to a load barrier. In addition to an object
> address, a colored object pointer contains information used by the load barrier to determine if some action needs to be taken before allowing a Java thread to use the pointer. For example, the object
> might have been relocated, in which case the load barrier will detect the situation and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the relocation/compaction phase, before pointers pointing into the reclaimed/reused regions have been fixed. This helps keep the general heap overhead
> down. It also means that there is no need to implement a separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This helps keep the runtime overhead down. It also means that it's easier to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the colored pointers. However, the versatile nature of this scheme allows us to store any type of information (as long as we can fit
> it into the pointer) and let the load barrier take any action it wants to based on that information. We believe this will lay the foundation for many future features. To pick one example, in a
> heterogeneous memory environment, this could be used to track heap access patterns to guide GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in non-GC subsystems in HotSpot, such as being able to concurrently unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen, either in the form of general improvements, or because a feature has found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have been working on JRockit and HotSpot projects for the past 8 years. I'm the initial author of ZGC, but many people have made
> significant contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK 10 repository, plus the latest ZGC patch set. Changes from the JDK 10 parent will be synced into ZGC periodically. Change review
> policy will be determined by the Lead and a consensus of Reviewers. Review is expected to be relaxed initially, but made more strict as we get closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion. Votes must be cast in the open on the discuss list. Replying to this message is sufficient if your mail program honors the
> Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Ioi Lam
In reply to this post by Stefan Karlsson
Vote: yes


On 10/25/17 12:45 PM, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will
> provide a home for the continued development of the Z Garbage
> Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally
> at Oracle so far, and we're now open-sourcing it so as to broaden the
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of
> relevant workloads. At the same time we want to acknowledge that we
> don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World
> phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java
> thread's perspective, the act of loading a reference field in a Java
> object is subject to a load barrier. In addition to an object address,
> a colored object pointer contains information used by the load barrier
> to determine if some action needs to be taken before allowing a Java
> thread to use the pointer. For example, the object might have been
> relocated, in which case the load barrier will detect the situation
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This
> helps keep the runtime overhead down. It also means that it's easier
> to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows
> us to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in
> non-GC subsystems in HotSpot, such as being able to concurrently
> unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Peter B. Kessler-2
In reply to this post by Stefan Karlsson
Vote: yes

                        ... peter

On 10/25/17 12:45 PM, Per Liden wrote:
> I hereby propose the creation of the ZGC Project with myself (Per Liden) as the Lead and the HotSpot Group as the sponsoring Group.
> ...
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

David Holmes
In reply to this post by Stefan Karlsson
Vote: yes.

David

On 26/10/2017 5:45 AM, Per Liden wrote:
> I hereby propose the creation of the ZGC Project with myself (Per Liden)
> as the Lead and the HotSpot Group as the sponsoring Group.
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Roman Kennke-2
In reply to this post by Stefan Karlsson
Vote: yes

Am 25. Oktober 2017 21:45:23 MESZ schrieb Per Liden <[hidden email]>:

>I hereby propose the creation of the ZGC Project with myself (Per
>Liden)
>as the Lead and the HotSpot Group as the sponsoring Group.
>
>In accordance with the OpenJDK guidelines [1], this project will
>provide
>a home for the continued development of the Z Garbage Collector, also
>known as ZGC. ZGC is a new garbage collector optimized for low latency
>and very large heaps. We've developed ZGC internally at Oracle so far,
>and we're now open-sourcing it so as to broaden the base of both
>contributors and users.
>
>ZGC has been designed with the following goals in mind:
>* Handle multi-terabyte heaps
>* GC pause times not exceeding 10ms
>* No more than 15% application throughput reduction compared to using
>G1
>
>We have strong ambitions to meet these goals for a large set of
>relevant
>workloads. At the same time we want to acknowledge that we don't see
>these goals as hard requirements for every conceivable workload. We are
>
>however currently able to meet or exceed these goals on some well-known
>
>industry standard benchmarks.
>
>At a glance, ZGC is a concurrent, currently single-generation,
>region-based, incrementally compacting collector. Stop-The-World phases
>
>are limited to root scanning, meaning GC pause times do not increase
>with the heap- or live-set size.
>
>While there is still work to do, the design and implementation is
>reasonably mature and stable. ZGC today executes the following GC
>tasks/phases concurrently:
>* Marking
>* Reference processing (java.lang.ref.*)
>* Relocation set selection
>* Relocation/Compaction
>
>And we're actively working on making the remaining GC tasks/phases
>concurrent. These are:
>* Weak root processing (StringTable, JNIWeakGlobalRefs)
>* Class unloading
>
>A core design principle/choice in ZGC is the use of load barriers in
>combination with colored object pointers (i.e. colored oops). This is
>what enables ZGC to do concurrent operations, such as object
>relocation,
>while Java application threads are running. From a Java thread's
>perspective, the act of loading a reference field in a Java object is
>subject to a load barrier. In addition to an object address, a colored
>object pointer contains information used by the load barrier to
>determine if some action needs to be taken before allowing a Java
>thread
>to use the pointer. For example, the object might have been relocated,
>in which case the load barrier will detect the situation and take
>appropriate action.
>
>Compared to alternative techniques, we believe the colored pointers
>scheme offers some very attractive properties. To name a few:
>
>* It allows us to reclaim and reuse memory during the
>relocation/compaction phase, before pointers pointing into the
>reclaimed/reused regions have been fixed. This helps keep the general
>heap overhead down. It also means that there is no need to implement a
>separate mark-compact algorithm to handle "Full GC".
>
>* It allows us to have relatively few and simple GC barriers. This
>helps
>keep the runtime overhead down. It also means that it's easier to
>implement, optimize and maintain the GC barrier code in our interpreter
>
>and JIT compilers.
>
>* We currently store marking and relocation related information in the
>colored pointers. However, the versatile nature of this scheme allows
>us
>to store any type of information (as long as we can fit it into the
>pointer) and let the load barrier take any action it wants to based on
>that information. We believe this will lay the foundation for many
>future features. To pick one example, in a heterogeneous memory
>environment, this could be used to track heap access patterns to guide
>GC relocation decisions to move rarely used objects to "cold storage".
>
>Much of the remaining work involves addressing latency issues in non-GC
>
>subsystems in HotSpot, such as being able to concurrently unlink stale
>entries in the StringTable. We hope and expect to see a fair bit of
>collaboration with people working on other garbage collectors in areas
>where we have a common interest.
>
>Some of the work coming out of the ZGC project has already been seen,
>either in the form of general improvements, or because a feature has
>found use cases outside of ZGC, such as:
>* Atomics re-write
>* GC Barrier API
>* Thread local handshakes
>
>I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
>been working on JRockit and HotSpot projects for the past 8 years. I'm
>the initial author of ZGC, but many people have made significant
>contributions since then.
>
>Special thanks to Stefan Karlsson, who has been working with me on ZGC
>since the very early phases of this project.
>
>The initial Reviewers and Committers will be (based on people who have
>contributed to ZGC development within Oracle so far):
>
>* Stefan Karlsson (Reviewer)
>* Erik Österlund (Committer)
>* Mikael Gerdin (Committer)
>* Kim Barret (Committer)
>* Nils Eliasson (Committer)
>* Rickard Bäckman (Committer)
>* Roland Westrelin (Committer)
>* Coleen Philimore (Committer)
>* Robin Ehn (Committer)
>* Gerard Ziemski (Committer)
>
>The initial source of this project will be based on a clone of a JDK 10
>
>repository, plus the latest ZGC patch set. Changes from the JDK 10
>parent will be synced into ZGC periodically. Change review policy will
>be determined by the Lead and a consensus of Reviewers. Review is
>expected to be relaxed initially, but made more strict as we get closer
>
>to integration.
>
>The project will host at least the following mailing list:
>
>* zgc-dev for developers
>
>Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
>Only current OpenJDK Members [1] are eligible to vote on this motion.
>Votes must be cast in the open on the discuss list. Replying to this
>message is sufficient if your mail program honors the Reply-To header.
>
>For Lazy Consensus voting instructions, see [2].
>
>Regards,
>Per Liden
>
>[1] http://openjdk.java.net/census#members
>[2] http://openjdk.java.net/projects/#new-project-vote

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

dalibor topic-2
Vote: Yes.



--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Mario Torre-5
In reply to this post by Stefan Karlsson
Vote: Yes

Cheers,
Mario

On Wed 25. Oct 2017 at 22:23, Per Liden <[hidden email]> wrote:

> I hereby propose the creation of the ZGC Project with myself (Per Liden)
> as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will provide
> a home for the continued development of the Z Garbage Collector, also
> known as ZGC. ZGC is a new garbage collector optimized for low latency
> and very large heaps. We've developed ZGC internally at Oracle so far,
> and we're now open-sourcing it so as to broaden the base of both
> contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of relevant
> workloads. At the same time we want to acknowledge that we don't see
> these goals as hard requirements for every conceivable workload. We are
> however currently able to meet or exceed these goals on some well-known
> industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World phases
> are limited to root scanning, meaning GC pause times do not increase
> with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object relocation,
> while Java application threads are running. From a Java thread's
> perspective, the act of loading a reference field in a Java object is
> subject to a load barrier. In addition to an object address, a colored
> object pointer contains information used by the load barrier to
> determine if some action needs to be taken before allowing a Java thread
> to use the pointer. For example, the object might have been relocated,
> in which case the load barrier will detect the situation and take
> appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This helps
> keep the runtime overhead down. It also means that it's easier to
> implement, optimize and maintain the GC barrier code in our interpreter
> and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows us
> to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in non-GC
> subsystems in HotSpot, such as being able to concurrently unlink stale
> entries in the StringTable. We hope and expect to see a fair bit of
> collaboration with people working on other garbage collectors in areas
> where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK 10
> repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get closer
> to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote
>
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Alan Bateman
In reply to this post by Stefan Karlsson
Vote: yes
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Erik Helin-2
In reply to this post by Stefan Karlsson
Vote: yes

Thanks,
Erik

On 10/25/2017 09:45 PM, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per Liden)
> as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will provide
> a home for the continued development of the Z Garbage Collector, also
> known as ZGC. ZGC is a new garbage collector optimized for low latency
> and very large heaps. We've developed ZGC internally at Oracle so far,
> and we're now open-sourcing it so as to broaden the base of both
> contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of relevant
> workloads. At the same time we want to acknowledge that we don't see
> these goals as hard requirements for every conceivable workload. We are
> however currently able to meet or exceed these goals on some well-known
> industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World phases
> are limited to root scanning, meaning GC pause times do not increase
> with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object relocation,
> while Java application threads are running. From a Java thread's
> perspective, the act of loading a reference field in a Java object is
> subject to a load barrier. In addition to an object address, a colored
> object pointer contains information used by the load barrier to
> determine if some action needs to be taken before allowing a Java thread
> to use the pointer. For example, the object might have been relocated,
> in which case the load barrier will detect the situation and take
> appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This helps
> keep the runtime overhead down. It also means that it's easier to
> implement, optimize and maintain the GC barrier code in our interpreter
> and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows us
> to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in non-GC
> subsystems in HotSpot, such as being able to concurrently unlink stale
> entries in the StringTable. We hope and expect to see a fair bit of
> collaboration with people working on other garbage collectors in areas
> where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK 10
> repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get closer
> to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote
Reply | Threaded
Open this post in threaded view
|

RE: CFV: New Project: ZGC

Markus Gronlund
In reply to this post by Stefan Karlsson
Vote: yes

-----Original Message-----
From: Per Liden
Sent: den 25 oktober 2017 21:45
To: [hidden email]
Subject: CFV: New Project: ZGC

I hereby propose the creation of the ZGC Project with myself (Per Liden) as the Lead and the HotSpot Group as the sponsoring Group.

In accordance with the OpenJDK guidelines [1], this project will provide a home for the continued development of the Z Garbage Collector, also known as ZGC. ZGC is a new garbage collector optimized for low latency and very large heaps. We've developed ZGC internally at Oracle so far, and we're now open-sourcing it so as to broaden the base of both contributors and users.

ZGC has been designed with the following goals in mind:
* Handle multi-terabyte heaps
* GC pause times not exceeding 10ms
* No more than 15% application throughput reduction compared to using G1

We have strong ambitions to meet these goals for a large set of relevant workloads. At the same time we want to acknowledge that we don't see these goals as hard requirements for every conceivable workload. We are however currently able to meet or exceed these goals on some well-known industry standard benchmarks.

At a glance, ZGC is a concurrent, currently single-generation, region-based, incrementally compacting collector. Stop-The-World phases are limited to root scanning, meaning GC pause times do not increase with the heap- or live-set size.

While there is still work to do, the design and implementation is reasonably mature and stable. ZGC today executes the following GC tasks/phases concurrently:
* Marking
* Reference processing (java.lang.ref.*)
* Relocation set selection
* Relocation/Compaction

And we're actively working on making the remaining GC tasks/phases concurrent. These are:
* Weak root processing (StringTable, JNIWeakGlobalRefs)
* Class unloading

A core design principle/choice in ZGC is the use of load barriers in combination with colored object pointers (i.e. colored oops). This is what enables ZGC to do concurrent operations, such as object relocation, while Java application threads are running. From a Java thread's perspective, the act of loading a reference field in a Java object is subject to a load barrier. In addition to an object address, a colored object pointer contains information used by the load barrier to determine if some action needs to be taken before allowing a Java thread to use the pointer. For example, the object might have been relocated, in which case the load barrier will detect the situation and take appropriate action.

Compared to alternative techniques, we believe the colored pointers scheme offers some very attractive properties. To name a few:

* It allows us to reclaim and reuse memory during the relocation/compaction phase, before pointers pointing into the reclaimed/reused regions have been fixed. This helps keep the general heap overhead down. It also means that there is no need to implement a separate mark-compact algorithm to handle "Full GC".

* It allows us to have relatively few and simple GC barriers. This helps keep the runtime overhead down. It also means that it's easier to implement, optimize and maintain the GC barrier code in our interpreter and JIT compilers.

* We currently store marking and relocation related information in the colored pointers. However, the versatile nature of this scheme allows us to store any type of information (as long as we can fit it into the
pointer) and let the load barrier take any action it wants to based on that information. We believe this will lay the foundation for many future features. To pick one example, in a heterogeneous memory environment, this could be used to track heap access patterns to guide GC relocation decisions to move rarely used objects to "cold storage".

Much of the remaining work involves addressing latency issues in non-GC subsystems in HotSpot, such as being able to concurrently unlink stale entries in the StringTable. We hope and expect to see a fair bit of collaboration with people working on other garbage collectors in areas where we have a common interest.

Some of the work coming out of the ZGC project has already been seen, either in the form of general improvements, or because a feature has found use cases outside of ZGC, such as:
* Atomics re-write
* GC Barrier API
* Thread local handshakes

I (Per Liden) am a member of the HotSpot GC team at Oracle, and have been working on JRockit and HotSpot projects for the past 8 years. I'm the initial author of ZGC, but many people have made significant contributions since then.

Special thanks to Stefan Karlsson, who has been working with me on ZGC since the very early phases of this project.

The initial Reviewers and Committers will be (based on people who have contributed to ZGC development within Oracle so far):

* Stefan Karlsson (Reviewer)
* Erik Österlund (Committer)
* Mikael Gerdin (Committer)
* Kim Barret (Committer)
* Nils Eliasson (Committer)
* Rickard Bäckman (Committer)
* Roland Westrelin (Committer)
* Coleen Philimore (Committer)
* Robin Ehn (Committer)
* Gerard Ziemski (Committer)

The initial source of this project will be based on a clone of a JDK 10 repository, plus the latest ZGC patch set. Changes from the JDK 10 parent will be synced into ZGC periodically. Change review policy will be determined by the Lead and a consensus of Reviewers. Review is expected to be relaxed initially, but made more strict as we get closer to integration.

The project will host at least the following mailing list:

* zgc-dev for developers

Votes are due by 23:59 CET on Wednesday, November 8, 2017.

Only current OpenJDK Members [1] are eligible to vote on this motion.
Votes must be cast in the open on the discuss list. Replying to this message is sufficient if your mail program honors the Reply-To header.

For Lazy Consensus voting instructions, see [2].

Regards,
Per Liden

[1] http://openjdk.java.net/census#members
[2] http://openjdk.java.net/projects/#new-project-vote
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Magnus Ihse Bursie
In reply to this post by Stefan Karlsson
Vote: yes

/Magnus

On 2017-10-25 21:45, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will
> provide a home for the continued development of the Z Garbage
> Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally
> at Oracle so far, and we're now open-sourcing it so as to broaden the
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of
> relevant workloads. At the same time we want to acknowledge that we
> don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World
> phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java
> thread's perspective, the act of loading a reference field in a Java
> object is subject to a load barrier. In addition to an object address,
> a colored object pointer contains information used by the load barrier
> to determine if some action needs to be taken before allowing a Java
> thread to use the pointer. For example, the object might have been
> relocated, in which case the load barrier will detect the situation
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This
> helps keep the runtime overhead down. It also means that it's easier
> to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows
> us to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in
> non-GC subsystems in HotSpot, such as being able to concurrently
> unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

roger riggs
In reply to this post by Stefan Karlsson
Vote: Yes

On 10/25/2017 3:45 PM, Per Liden wrote:
> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Volker Simonis
In reply to this post by Stefan Karlsson
Hi Per,

first of all I want to notice that you haven't gone through the
optional but nevertheless recommended [1] step of discussing your
project before proposing and voting for it. This is unfortunate,
because it again confirms the impression that projects started by
Oracle are somehow treated preferentially compared to projects
proposed by external contributors.

For example the Shenandoah project had to go through a six month
interrogation [2,3] process before they could finally start the call
for voting on their project creation.

I think it would be beneficial for the OpenJDK project if internal and
external contributors would be treated equally (well :)

Conceptually I would be very interested in the relationship between
ZGC and Shenandoah as they obviously both have the same goals and
maybe even share some of the same ideas. As Shenandoah is in the
OpenJDK since more than two years and publicly available even longer,
I suppose you are aware of it.

1. What are the benefits / advantages of ZGC over Shenandoah?
2. Does it make sense to have both, ZGC and Shenandoah in the main code line?
2.1 If yes, why?
2.2 If no, why you propose ZGC at all and not contribute to
Shenandoah? It's there since more than two years! That you already
worked on ZGC for some time as well doesn't count here because we (the
OpenJDK community) couldn't see that and had no chance to contribute
to it.
3. Oracle has just deprecated CMS and other collectors because
according to Oracle it was just too expensive to maintain that many
collectors in parallel. Now I wonder how yet another new collector
fits into the picture?

The answer to all these question would be important for me before
casting a qualified vote.

Thank you and best regards,
Volker

[1] http://openjdk.java.net/projects/#new-project
[2] http://mail.openjdk.java.net/pipermail/discuss/2015-February/003680.html
[3] http://mail.openjdk.java.net/pipermail/discuss/2015-August/003767.html

On Wed, Oct 25, 2017 at 9:45 PM, Per Liden <[hidden email]> wrote:

> I hereby propose the creation of the ZGC Project with myself (Per Liden) as
> the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will provide a
> home for the continued development of the Z Garbage Collector, also known as
> ZGC. ZGC is a new garbage collector optimized for low latency and very large
> heaps. We've developed ZGC internally at Oracle so far, and we're now
> open-sourcing it so as to broaden the base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of relevant
> workloads. At the same time we want to acknowledge that we don't see these
> goals as hard requirements for every conceivable workload. We are however
> currently able to meet or exceed these goals on some well-known industry
> standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation, region-based,
> incrementally compacting collector. Stop-The-World phases are limited to
> root scanning, meaning GC pause times do not increase with the heap- or
> live-set size.
>
> While there is still work to do, the design and implementation is reasonably
> mature and stable. ZGC today executes the following GC tasks/phases
> concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is what
> enables ZGC to do concurrent operations, such as object relocation, while
> Java application threads are running. From a Java thread's perspective, the
> act of loading a reference field in a Java object is subject to a load
> barrier. In addition to an object address, a colored object pointer contains
> information used by the load barrier to determine if some action needs to be
> taken before allowing a Java thread to use the pointer. For example, the
> object might have been relocated, in which case the load barrier will detect
> the situation and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers scheme
> offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the relocation/compaction
> phase, before pointers pointing into the reclaimed/reused regions have been
> fixed. This helps keep the general heap overhead down. It also means that
> there is no need to implement a separate mark-compact algorithm to handle
> "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This helps
> keep the runtime overhead down. It also means that it's easier to implement,
> optimize and maintain the GC barrier code in our interpreter and JIT
> compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows us to
> store any type of information (as long as we can fit it into the pointer)
> and let the load barrier take any action it wants to based on that
> information. We believe this will lay the foundation for many future
> features. To pick one example, in a heterogeneous memory environment, this
> could be used to track heap access patterns to guide GC relocation decisions
> to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in non-GC
> subsystems in HotSpot, such as being able to concurrently unlink stale
> entries in the StringTable. We hope and expect to see a fair bit of
> collaboration with people working on other garbage collectors in areas where
> we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen, either
> in the form of general improvements, or because a feature has found use
> cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have been
> working on JRockit and HotSpot projects for the past 8 years. I'm the
> initial author of ZGC, but many people have made significant contributions
> since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC since
> the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK 10
> repository, plus the latest ZGC patch set. Changes from the JDK 10 parent
> will be synced into ZGC periodically. Change review policy will be
> determined by the Lead and a consensus of Reviewers. Review is expected to
> be relaxed initially, but made more strict as we get closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion. Votes
> must be cast in the open on the discuss list. Replying to this message is
> sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Kumar Srinivasan
In reply to this post by Stefan Karlsson
Vote: yes

On 10/25/2017 12:45 PM, Per Liden wrote:

> I hereby propose the creation of the ZGC Project with myself (Per
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will
> provide a home for the continued development of the Z Garbage
> Collector, also known as ZGC. ZGC is a new garbage collector optimized
> for low latency and very large heaps. We've developed ZGC internally
> at Oracle so far, and we're now open-sourcing it so as to broaden the
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of
> relevant workloads. At the same time we want to acknowledge that we
> don't see these goals as hard requirements for every conceivable
> workload. We are however currently able to meet or exceed these goals
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation,
> region-based, incrementally compacting collector. Stop-The-World
> phases are limited to root scanning, meaning GC pause times do not
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is
> reasonably mature and stable. ZGC today executes the following GC
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in
> combination with colored object pointers (i.e. colored oops). This is
> what enables ZGC to do concurrent operations, such as object
> relocation, while Java application threads are running. From a Java
> thread's perspective, the act of loading a reference field in a Java
> object is subject to a load barrier. In addition to an object address,
> a colored object pointer contains information used by the load barrier
> to determine if some action needs to be taken before allowing a Java
> thread to use the pointer. For example, the object might have been
> relocated, in which case the load barrier will detect the situation
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the
> relocation/compaction phase, before pointers pointing into the
> reclaimed/reused regions have been fixed. This helps keep the general
> heap overhead down. It also means that there is no need to implement a
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This
> helps keep the runtime overhead down. It also means that it's easier
> to implement, optimize and maintain the GC barrier code in our
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the
> colored pointers. However, the versatile nature of this scheme allows
> us to store any type of information (as long as we can fit it into the
> pointer) and let the load barrier take any action it wants to based on
> that information. We believe this will lay the foundation for many
> future features. To pick one example, in a heterogeneous memory
> environment, this could be used to track heap access patterns to guide
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in
> non-GC subsystems in HotSpot, such as being able to concurrently
> unlink stale entries in the StringTable. We hope and expect to see a
> fair bit of collaboration with people working on other garbage
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen,
> either in the form of general improvements, or because a feature has
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have
> been working on JRockit and HotSpot projects for the past 8 years. I'm
> the initial author of ZGC, but many people have made significant
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10
> parent will be synced into ZGC periodically. Change review policy will
> be determined by the Lead and a consensus of Reviewers. Review is
> expected to be relaxed initially, but made more strict as we get
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list. Replying to this
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote

Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

Andrew Haley
In reply to this post by Volker Simonis
On 26/10/17 16:42, Volker Simonis wrote:

> 1. What are the benefits / advantages of ZGC over Shenandoah?
> 2. Does it make sense to have both, ZGC and Shenandoah in the main code line?
> 2.1 If yes, why?
> 2.2 If no, why you propose ZGC at all and not contribute to
> Shenandoah? It's there since more than two years! That you already
> worked on ZGC for some time as well doesn't count here because we (the
> OpenJDK community) couldn't see that and had no chance to contribute
> to it.
> 3. Oracle has just deprecated CMS and other collectors because
> according to Oracle it was just too expensive to maintain that many
> collectors in parallel. Now I wonder how yet another new collector
> fits into the picture?
>
> The answer to all these question would be important for me before
> casting a qualified vote.

Yep.  It would be unfortunate if it appeared that all this was being
done without the preparation required of external contributors.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: CFV: New Project: ZGC

dalibor topic-2
In reply to this post by Volker Simonis
On 26.10.2017 17:42, Volker Simonis wrote:
> For example the Shenandoah project had to go through a six month
> interrogation [2,3] process before they could finally start the call
> for voting on their project creation.

The Shenandoah discussion in February had run its course within 9 days.

Once Roman wanted to initiate the vote on the Project in March, it
became clear that the HotSpot Group Lead at the time was no longer at
Oracle, and no longer actively acting as Group Lead, and therefore
unable to get to sponsor the Project, as required in the Bylaws for the
vote. [0]

While an inactive Group Lead could have been removed by votes of the
HotSpot Group's Members (or in exceptional circumstances, by a vote of
the Governing Board), I think that it's preferable for a person that is
no longer acting as a Group Lead to resign if no longer interested in
the role, than to attempt to vote them out.

The resignation happened three months later, in June. [1] The vote for a
  new Group Lead was completed by the end of June. [2] The Governing
Board confirmed the new Group Lead in July. [3]

The delay between the initial discussion of Shenandoah and the Project
vote had nothing to do with interrogations of any kind.

cheers,
dalibor topic

[0] http://mail.openjdk.java.net/pipermail/discuss/2015-March/003701.html
[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018933.html
[2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019273.html
[3] http://mail.openjdk.java.net/pipermail/gb-discuss/2015-July/thread.html

--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
123