Strange GC behaviour,

[Dang Nhan Nguyen]

Hi,

Thank you for your update.
I apply CR is 7112034 and also try with -XX:+ParallelRefProcEnabled:


-    While applying CR is 7112034, CMS still leaves about the same number of objects/ref marked for the remark phase comparing to before applying the CR. Which means the CR make no (or little) change to the number of references  processed during the concurrent marking phase. How can this be explained?

-    When I use -XX:+ParallelRefProcEnabled, performance is worse than not using this option. So, when I enable this, how many threads were used for this reference processing (in a ratio of ParallelGCThreads and ConcGCThreads)?



>From further information, in one application, 100k-200k references were left to the remark phase, and in  another they are 1.5m references.

Best,
-Nhan

From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
Sent: Thursday, December 08, 2011 2:44 AM
To: Dang Nhan Nguyen
Cc: hotspot-gc-dev at openjdk.java.net
Subject: Re: Strange GC behaviour,

Hi Nhan --

Make sure you have the recent fix to Reference object processing when doing
MT/Parallel marking with CMS; i don't have the CR handy, but the fix was pushed by
Stefan not long ago. (The workaround was to disable parallel concurrent marking via
-XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that,
depending on yr platform, might compromise yr benchmarking results.)

More inline below:-
On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen <nhann at chalmers.se<mailto:nhann at chalmers.se>> wrote:
Hi guys,

I am benchmarking CMS collector and found it strange that there are many objects left in remark phase.

When I check the issue again by only running foreground CMS (I changed the source code a bit to force CMS running in foreground), so there is no promotion during collecting  (so no objects marked during Preclean and Abortable Preclean phase). Even in this case, I found that there are still many objects left in remark phase (in lusearch and tomcat in Dacapo benchmark, they are 10 times and 1/3 of number of objects marked in concmarking phase, while in suflow, they are just about 100 objects/refs). Most (maybe ALL) of these objects marked in remark phase were processed by refProcessingWork(). In turn, this refProcessingWork() run in single thread mode. The performance was reduced a lot because of this.

-XX:+ParallelRefProcEnabled uses multiple threads to do that phase.


My questions are:
1. What kinds of references were processed by refProcessingWork()? weak and soft ref? what are exactly they are?

all objects of type java.lang.ref.Reference (includes WeakReferencem=, SoftReference, FinalReference, PhantomReference).

2. While I only run CMS in stop-the-world, why are there still many objects left to be processed by remark, in particular here is refProcessingWork()? Why aren't these references/objects processed in concurrent marking phase?

I am not sure I understand the question. What do you mean by "run CMS in stop-the-world"? Note that Reference objects are processed
by all kinds of collectors, young gen (minor) or whole heap (major), stop-world or concurrent. The volume of those objects may
vary a bit between them based on the heap size, NewRatio etc.

hope that helped.
-- ramki

Best,
-Nhan Nguyen

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