Fw: Shenandoah: How small is small?

[Aleksey Shipilev]

Hi,

I am running my performance tests routinely with 2 Gb heaps (see e.g.
[1]), and Shenandoah works well there, This does not mean these small
heaps are the target, but says something about the collector.

Try it, the code did improve since 2014.

Thanks,
-Aleksey

[1] http://cr.openjdk.java.net/~shade/scratch/Fragger.java

On 11/17/2016 04:25 PM, org.openjdk at io7m.com wrote:
> [Reposting to shenandoah-dev@ on the advice of Martijn Verburg]
> 
> 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/
>