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