There's a specific shenandoah-dev list - you may get a more accurate response there as it's a moving target.
Cheers, Martijn On 15 November 2016 at 17:19, <org.open...@io7m.com> wrote: > Hello. > > I've been watching the development of Shenandoah since it began. As a > developer of software with mildly soft-realtime requirements (games, > primarily), I'm always eager to see advances that can reduce GC pause > times. Although right now I don't have a GC problem (typically, my > pauses for minor GCs are well below 16ms and therefore are not > perceptible given the usual 30hz/60hz game loop), I still feel that I > have to be more conscious of allocation rates than feels natural in > order to avoid producing too much garbage. I sometimes find myself > avoiding better abstractions and immutable objects simply because I > want to avoid allocations. Escape analysis helps, but sometimes those > objects really do need to hang around. Value types will also help! > > I've read in JEP 189 that Shenandoah is intended to try to reduce pause > times on +100gb heaps, and a rather outdated blog post online [0] > suggested that a 512mb heap is simply too small to run at all. The > software I write is written under the general assumption that 1GB of > memory will be a minimum requirement - this includes both the JVM heap > and any allocated native memory. > > Right now I'm still using ParNew, although I'll likely move to G1 if it > becomes the default in JDK9. Is Shenandoah likely to be an improvement > for my use case? > > Regards, > Mark > > [0] https://www.jclarity.com/2014/03/12/shenandoah-experiment-1- > will-it-run-pcgen/ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > >
_______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
