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

Vitaly Davidovich vitalyd at gmail.com
Sat May 14 13:55:48 UTC 2016


On Saturday, May 14, 2016, Simone Bordet <simone.bordet at gmail.com> wrote:

> Ciao,
>
> On Fri, May 13, 2016 at 4:02 PM, Christine Flood <chf at redhat.com
> <javascript:;>> wrote:
> > OK, I've put together a pdf document which summarizes our changes.
> >
> > I'm happy to go into more detail or answer questions.
>
> At the end of the section "Source Code Changes":
>
> "We have measured their execution cost and have found so significant
> overheap when running G1 with and without Shenandoah code."
>
> I'm not sure I understand "found so significant overheap", can you
> please expand ?

I read that as "found no significant overhead".

>
> I read that Brooks pointers have not be often be considered because of
> the high cost associated with indirection, but a blog from Roman
> (https://rkennke.wordpress.com/2016/02/08/shenandoah-performance/)
> seems to show that perhaps this belief should be re-evaluated.
>
> Do you have any further insights that you can share on the good
> performance of Shenandoah ?

I'd also be interested in a comparison with Azul's C4 design.

>
> Thanks !
>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160514/015eb067/attachment.htm>


More information about the hotspot-gc-dev mailing list