Using -XX:+UseSerialGC with one JVM per core?

[Kevin Burton]

I was reading Martin's new GC article and I realized that it would be rather silly to run a parallel GC when you are running one JVM pre core.

That's what we tend to do in production to avoid JVM synchronized locks (SSL, Charsets, etc) but also because some of our apps are event sourced and we run one per port... 

Seems like a stupid idea to run the Parallel GC if you're running one JVM per core. The parallelism is just going to run at a slower speed because other cores are being used.  Further, if it DOES use another core you're going to get cache misses.

I've thought about just setting the processor affinity on startup to prevent this from happening.  

I haven't read much about the SerialGC though and I'm not sure how much recent development it has had.  Another option could be to use less parallel GC threads.

[Jason Koch]

Kevin - 

In my opinion, It's the same game - latency vs throughput (vs heap size & working set). Generally I agree, parallel is pointless if you're only allocated a single core.

Keep your promotion "traffic" low and you will get very few full GCs. If you can keep your application to minor GCs, then it doesn't matter about your full GC strategy.

If you're after low latency and still triggering full GC, you will need either a small heap or you will need at least a concurrent gc (even if you are on one core). Parallel won't help, but concurrent will spread the cost out and avoid spikes. With a small heap size a serial GC won't take a huge amount of time.

Jason

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kirk Pepperdine]

we've had luck with iCMS as well as serial. The serial implementation is very very solid and very fast.

-- Kirk