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

[kirk.pepperdine at gmail.com]

Hi Christine,

Thank you for summarizing the changes. It makes is very useful to evaluate the changes made. I especially like how you were able to integrate the collector into the existing code base with such a light touch. I don’t see anything potentially destabilizing in the changes.

The question I do have is do you think this collector will work well if with memory dead-rekoning schemes that may show up in the JVM? I asked because the extra level of indirection that is present would seem to further the current problem of pointer chasing that often interferes with pre-fetching. I’m not really speaking to value types here as although I believe that is beneficial/helpful effort, it doesn’t completely allow developers to control the memory layout of their data structures.

Regards,
Kirk

> On May 13, 2016, at 4:02 PM, Christine Flood <chf at redhat.com> wrote:
> 
> OK, I've put together a pdf document which summarizes our changes.
> 
> I'm happy to go into more detail or answer questions.
> 
> 
> 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
>> 
> <ShenandoahProposal.pdf>