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

Erik Helin erik.helin at oracle.com
Mon Jun 13 08:35:31 UTC 2016


On 2016-06-09, Christine Flood wrote:
> 
> 
> ----- Original Message -----
> > From: "Erik Helin" <erik.helin at oracle.com>
> > To: "Christine Flood" <chf at redhat.com>
> > Cc: hotspot-dev at openjdk.java.net
> > Sent: Wednesday, May 25, 2016 5:33:08 AM
> > Subject: Re: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
> > ...
> > Ok, then I would like you to make sure that compiling the Shenandoah
> > code is controlled with a configure variable, similar to jvmci, shark,
> > dtrace, vm-structs, etc:
> > 
> > sh configure --with-jvm-features=shenandoah
> > 
> >
> 
> There are some refactorings that we've done to make sharing code between G1 and Shenandoah easier.
> We'd like to put those back upstream as is.  They make merges much simpler for us.

Do you mean the patch that Roman sent to hotspot-gc-dev? I will look
at the patch and give my feedback in that email thread.

> We can isolate the Shenandoah specific barriers with a flag as you suggest but may we request that the
> flag be left on by default.  This provides the option to turn Shenandoah off if there is an 
> issue but provides us with more testing/exposure.

Given that the barriers is a new and intrusive change, the configure
flag will have to start out by being off by default. Once the code has
gone through significant testing and there is support for all the
OpenJDK platforms, then we can have a discussion again about having the
configure flag being on by default. The stability of OpenJDK is very
important, it is better to introduce new, intrusive changes gradually.

Thanks,
Erik

> Christine


More information about the hotspot-dev mailing list