CMSEdenChunksRecordAlways & CMSParallelInitialMarkEnabled

[Jon Masamitsu]

On 06/12/2014 09:16 PM, graham sanderson wrote:
> Hi, I hope this is the right list for this question:
>
> I was investigating abortable preclean timeouts in our app (and 
> associated long remark pause) so had a look at the old jdk6 code I had 
> on my box, wondered about recording eden chunks during certain eden 
> slow allocation paths (I wasn’t sure if TLAB allocation is just a CAS 
> bump), and saw what looked perfect in the latest code, so was excited 
> to install 1.7.0_60-b19
>
> I wanted to ask what you consider the stability of these two options 
> to be (I’m pretty sure at least the first one is new in this release)
>
> I have just installed locally on my mac, and am aware of 
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809 which I 
> could reproduce, however I wasn’t able to reproduce it without 
> -XX:-UseCMSCompactAtFullCollection (is this your understanding too?)

Yes.

>
> We are running our application with 8 gig young generation (6.4g 
> eden), on boxes with 32 cores… so parallelism is good for short pauses
>
> we already have
>
> -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGC
> -XX:+CMSParallelRemarkEnabled
>
> we have seen a few long(isn) initial marks, so
>
> -XX:+CMSParallelInitialMarkEnabled sounds good
>
> as for
>
> -XX:+CMSEdenChunksRecordAlways
>
> my question is: what constitutes a slow path such an eden chunk is 
> potentially recorded… TLAB allocation, or more horrific things; 
> basically (and I’ll test our app with -XX:+CMSPrintEdenSurvivorChunks) 
> is it likely that I’ll actually get less samples using 
> -XX:+CMSEdenChunksRecordAlways in a highly multithread app than I 
> would with sampling, or put another way… what sort of app allocation 
> patterns if any might avoid the slow path altogether and might leave 
> me with just one chunk?

Fast path allocation is done from TLAB's.  If you have to get
a new TLAB, the call to get the new TLAB comes from compiled
code but the call is into the JVM and  that is the slow path where
the sampling is done.

Jon

>
> Thanks,
>
> Graham
>
> P.S. less relevant I think, but our old generation is 16g
> P.P.S. I suspect the abortable preclean timeouts mostly happen after a 
> burst of very high allocation rate followed by an almost complete 
> lull… this is one of the patterns that can happen in our application

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140616/66fbb71b/attachment.htm>