CMSEdenChunksRecordAlways & CMSParallelInitialMarkEnabled

[graham sanderson]

Thanks Jon; that’s exactly what i was hoping

On Jun 16, 2014, at 1:27 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:

> 
> 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/b3944a13/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1574 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140616/b3944a13/smime.p7s>