Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

[Erik Helin]

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.

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?

Thanks,
Erik

> 
> Christine
> 
> 
> ----- 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 [1] 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 [2], 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
> > 
> > 
> > [1] http://openjdk.java.net/jeps/189
> > [2] http://openjdk.java.net/jeps/1
> >