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

[Christine Flood]

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
> > >
> >
>