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

[Vitaly Davidovich]

Thanks Christine, it's clearer now.  Doesn't the forwarding pointer mean
that heap consumption will be larger (I think someone on this thread may
have already noted that), especially on large object-rich heaps? That's
going to be an extra word per object, it seems.  I'm guessing the simpler
implementation outweighs this concern?

Thanks

Sent from my phone
On Feb 5, 2014 10:45 AM, "Christine Flood" <chf at redhat.com> wrote:

>
>
> The pause times should be similar between Shenandoah and C4.  We both
> eliminate
> stop the world evacuation time.  The only difference is in how we do it.
>
> Their strategy is to memory protect regions which are targeted for
> evacuation.
> If you attempt to read or write from one of those regions you hit a trap,
> evacuate the object (or read the forwarding pointer) , and continue on
> with the
> to space copy of the object.
>
> Our strategy is to add a level of indirection to heap accesses to find the
> current copy of the object.
>
> We choose our solution because we believe it is simpler.  It will work on
> any machine
> architecture that supports CAS.  It is interchangeable with the other
> collectors
> that are in OpenJDK.
>
> I would love to see C4 ported to OpenJDK as well.  A head to head
> performance
> comparison would be fascinating.
>
>
>
> 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: Tuesday, February 4, 2014 8:27:04 PM
> > Subject: Re: JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage
> Collector
> >
> > Hi Roman,
> >
> > I know I asked this question initially, but don't feel that I quite
> > understood Christine's answer: what can we expect, in terms of gc
> > performance, as compared to Azul C4? As far as I know, C4 is a software
> > only collector as well (Azul CPUs have some hardware instructions to make
> > it faster, but it also runs on x64).  C4 claims some pretty impressive
> > pause times, so why not follow their design? I think they (Azul) have at
> > least 1 white paper on the algorithms/design.  I'm framing the question
> > this way not to doubt what you guys are doing, but rather understand the
> > thinking behind taking your approach; I can only surmise that the folks
> > involved researched current state of the art in this space, and must have
> > some reasons for going with Brooks style forwarding pointers.
> >
> > Thanks
> >
> > Sent from my phone
> > On Feb 4, 2014 6:42 PM, "Roman Kennke" <rkennke at redhat.com> wrote:
> >
> > > Hi Krystal,
> > >
> > >
> > > > I'd like to ask a couple of questions about the barriers, out of
> > > > curiosity.
> > > >
> > > >
> > > > The JEP says:
> > > >
> > > >
> > > > "...All reads by the Java Threads indirect through this forwarding
> > > > pointer. All writes to objects in targeted regions must first copy
> the
> > > > object and then write to the object in its new location."
> > > >
> > > >
> > > >
> > > > Does this mean Shenandoah employs both read and write barriers?
> > >
> > > Yes.
> > >
> > > >  The read barrier is a Brooks-style barrier, but the write barrier is
> > > > more than a plain SATB write barrier (as in G1), right?
> > >
> > > Right.
> > >
> > > > Will Shenandoah try to reuse the existing write barrier logic in
> > > > HotSpot and extend it to catch all field writes as opposed to just
> > > > reference field writes, or will it use some other form of write
> > > > barrier?
> > >
> > > It uses the G1 barrier for SATB and extends it for the preemptive
> > > copying.
> > >
> > > We don't use memory protection tricks ;-) Actually we can't, if we
> > > protecting our from-spaces, which would be a great thing to do, at
> least
> > > for debugging, we couldn't update the brooks pointers any more when we
> > > do the evacuation.
> > >
> > > Best regards,
> > > Roman
> > >
> > > > e.g. The Chakra JavaScript engine from Microsoft apparently uses a
> > > > write barrier implemented via memory protection trick, as noted in
> one
> > > > of their blog
> > > > posts:
> > >
> http://blogs.msdn.com/b/ie/archive/2012/06/13/advances-in-javascript-performance-in-ie10-and-windows-8.aspx
> > > >
> > > >
> > > > "Because Chakra's collector works concurrently with the main script
> > > > thread, the running script may modify or create new objects on pages
> > > > that have already been processed. To make sure such objects aren't
> > > > prematurely collected, Chakra write-protects pages before the mark
> > > > phase starts. Pages that have been written to during the mark phase
> > > > must be later rescanned on the main script thread. Because leaf
> > > > objects don't require such processing, pages from the leaf object
> > > > space don't need to be write-protected or rescanned later. This saves
> > > > precious time on the main script thread, reducing pauses."
> > > >
> > > >
> > > > Thanks,
> > > > Kris
> > > >
> > > >
> > > > On Fri, Jan 17, 2014 at 11:28 AM, 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140205/ec64b098/attachment.htm>