Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
david.holmes at oracle.com
Tue May 17 02:04:07 UTC 2016
On 16/05/2016 10:44 PM, Erik Helin wrote:
> I'm moving this thread to hotspot-dev since this JEP affects all of
> hotspot. I guess that the members from the runtime team and compiler
> team will want to comment on the changes to the interpreter, C1 and C2.
> On 2016-05-13, Christine Flood wrote:
>> OK, I've put together a pdf document which summarizes our changes.
For the benefit of others:
> Thank you for writing this up. Will you incorporate most of this
> document into the JEP?
>> I'm happy to go into more detail or answer questions.
> Reading through the document, I have a few initial high-level questions:
> - Which platforms does Shenandoah run on (CPUs/OSs)? Which platforms do
> you intend Shenandoah to run on?
> - For the goal of the JEP, do you have any particular benchmark in mind
> for determining when you have reached the goal? You have stated less
> than 100 ms pauses on 100 GB, but variables such as allocation rate,
> live set, etc. also tend to affect the GC. It might be easier to
> determine that you have reached your goal if you have a specific setup
> (OS, CPU, RAM) and a specific benchmark in mind.
> - When you state "most" GCs will be below 100 ms, do you have any number
> in mind? 99% of all GCs? 99.9%?
> - Who will maintain the Shenadoah code?
> Reading through the JEP, I noticed the line "...as opposed to G1 which
> focuses on young generation collection to help limit remembered-set
> size." The main reason for the young collections in G1 is to improve
> throughput, not to limit the size of the remembered sets. If an
> application follows the generational hypothesis, then a young generation
> can be quite a boost to throughput. We still have a remembered set per
> young region, but it only keeps track of pointers from old regions to
> young regions (not pointers between young regions). Would you please
> remove this statement from the JEP?
>> ----- Original Message -----
>>> From: "mark reinhold" <mark.reinhold at oracle.com>
>>> To: hotspot-gc-dev at openjdk.java.net, "Christine Flood" <chf at redhat.com>, "Roman Kennke" <rkennke at redhat.com>
>>> Sent: Wednesday, May 4, 2016 10:56:21 AM
>>> Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
>>> HotSpot GC developers -- Christine recently moved this JEP  to the
>>> Submitted state. Roman has made point proposals for some preparatory
>>> changes but there's been little response, so far, from anyone else on
>>> this list. As noted in JEP 1 , having consensus around a proposal
>>> is an essential part of moving a JEP forward. I'd therefore like to
>>> hear your views, not just on Roman's first proposals but on Shenandoah
>>> as a whole, especially with regard to the additional read and write
>>> barriers that would be needed and the potential for those to affect
>>> the existing collectors and also the run-time system.
>>> Christine and Roman -- I think it'd help for you to post a detailed
>>> plan of all that you'd want to change outside of Shenandoah itself, so
>>> that others can understand its potential impact. Such a plan would be
>>> easier to evaluate than a series of point changes, and can eventually
>>> be merged into the text of the JEP for the record.
>>> - Mark
>>>  http://openjdk.java.net/jeps/189
>>>  http://openjdk.java.net/jeps/1
More information about the hotspot-dev