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

[Vitaly Davidovich]

Also, cache misses associated with forwarding pointer - is that deemed
"acceptable" and not anticipated to cause perf loss (vs C4 at least)?

Sent from my phone
On Feb 5, 2014 2:22 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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/4e534f9d/attachment.htm>