G1:long remark pauses

[Richard Jones]

Thomas et al

Interesting. We took a look at reference processing in the context f building a fully on-the-fly copying collector for Jikes RVM. Our bottom line was that we found that the time to process references, in either stop-the-world fashion or by blocking any mutator that calls Reference.get(), was significant for the benchmarks we used (DaCapo) though not nearly as long as this. However, in our fully on-the-fly collector, although the length of the reference processing phase was longer, mutators ran concurrently so we eliminated pauses. It was also important to use deletion (snapshot at the beginning) rather than insertion (incremental update) barriers.

While I realise this is probably of no immediate help to you :-), details will be published at ISMM 2014. You can find our paper at http://www.cs.kent.ac.uk/projects/gc/mirrorgc/.

Regards
Richard

Richard Jones | Professor of Computer Systems | University of Kent
School of Computing, University of Kent, Canterbury, Kent CT2 7NF, UK
T +44 1227 827943 | F +44 1227 762811 | W http://www.cs.kent.ac.uk/~rej/
The Garbage Collection Handbook: The Art of Automatic Memory Management 

On 16 May 2014, at 11:58, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

> 
> Hi Thomas,
> 
> It looks like the application is using a lot of Reference objects. The time spent in remark is dominated by reference processing. See the attached graph generated from the log file you sent.
> 
> You can try to see if adding -XX:+ParallelRefProcEnabled improves the situation.
> 
> If the customer is interested in updating their application they might want to see if they can reduce the number of java.lang.ref.Reference objects they use.
> 
> Hths,
> Bengt
> 
> 
> On 2014-05-16 10:26, Thomas Viessmann wrote:
>> Hi,
>> 
>> 
>> I've been tuning a Java 7u51, Solaris 10, T4 system with 24G heap.
>> My customer is not very happy with the remark pauses of  up to 2 seconds.
>> -XX:ParallelGCThreads=48 turned out to be the optimum. Here is the log file
>> which contains the java args at the top:
>> 
>> http://aubing.de.oracle.com/gclog/gc_log_03052014.log
>> 
>> Any idea to drive the remark stop times further down?
>> 
>> 
>> Thanks and Regards
>> 
>> Thomas
> 
> <remarks.png>

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