JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (original) (raw)

Christine Flood chf at redhat.com
Sat Jan 18 16:12:58 UTC 2014

Never slow down the guy that's doing productive work unless you absolutely have to.

Christine

----- Original Message -----

From: "Vitaly Davidovich" <vitalyd at gmail.com> To: "Christine Flood" <chf at redhat.com> Cc: "Roman Kennke" <rkennke at redhat.com>, hotspot-gc-dev at openjdk.java.net Sent: Friday, January 17, 2014 5:49:00 PM Subject: Re: JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

What's the advantage of not copying and fixing up the pointer in a read barrier issued by a mutator, ala Azul? Having mutators help out with copying seems good on the surface. What's the catch? Sent from my phone On Jan 17, 2014 3:43 PM, "Christine Flood" <chf at redhat.com> wrote: > > Hi > > Thanks for asking the question. Radio silence was making me paranoid. > > There are two obvious approaches to concurrent evacuation. > > One way is to trap when anyone tries to read an object in a from region > and cause that > object to be evacuated. That's what Azul does. > > Our approach is to have a fowarding pointer associated with an object. > The read barrier is just > a simple additional read to figure out whether the object is where you > thought > it was or if it has moved. > > > Our read barriers never cause object copying and we are a software only > solution. > This means that we will run anywhere that the other Java collectors do. > > You can choose Shenandoah at runtime like you would any other GC. > > Christine > > > ----- Original Message ----- > > From: "Vitaly Davidovich" <vitalyd at gmail.com> > > To: "Roman Kennke" <rkennke at redhat.com> > > Cc: hotspot-gc-dev at openjdk.java.net > > Sent: Friday, January 17, 2014 3:19:58 PM > > Subject: Re: JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage > Collector > > > > Any chance you guys can highlight some notable differences between this > > collector and Azul's C4 collector? I can see both employ read barriers, > but > > can't quite make out what else is there. > > > > Also, will this also require any changes to kernel in order to support > the > > low pause goals? IIRC, Azul had problems with Linux because the memory > > manager didn't support bulk map/unmap operations, or something like that. > > This also begs the question of whether this new collector will be biased > > towards linux/Unix systems, or whether windows will get the same love. > > > > Thanks > > > > Sent from my phone > > On Jan 17, 2014 2:31 PM, "Roman Kennke" <rkennke at redhat.com> wrote: > > > > Hi there, > > > > Sorry being so silent... we are very happy that the Shenandoah JEP has > > finally been posted and would welcome any comments, questions, > > discussion from the community. > > > > Cheers, > > Roman > > > > Am Mittwoch, den 15.01.2014, 11:49 -0800 schrieb > > mark.reinhold at oracle.com: > > > Posted: http://openjdk.java.net/jeps/189 > > > > > > - Mark > > >

More information about the hotspot-gc-dev mailing list