RFR(XXS): 8153176: ParOldGC's ParallelTaskTerminator peeks wrong TaskQueueSet (original) (raw)

Reingruber, Richard richard.reingruber at sap.com
Thu Mar 31 15:31:15 UTC 2016

Hi Mikael,

Mikael> As I mentioned in the bug I think the same problem affects parallel Mikael> reference processing as well, see RefProcTaskExecutor::execute in Mikael> pcTasks.cpp.

Oh cool you saw this! Should I change this, too?

Mikael> Another fun thing is that if there are only object arrays on any Mikael> thread's work stealing queue then work stealing also breaks down, Mikael> because the terminator doesn't check the _objarray_queues.

Yes, I noticed this as well. If another thread is processing a large object array, then the elements will show up on its marking stack. This will let the thread spinning in offer_termination() return and continue in StealMarkingTask::do_it(), where it will try to steal from the _objarray_queues. I thought this might be sufficient.

Cheers, Richard.

-----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Donnerstag, 31. März 2016 16:17 To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(XXS): 8153176: ParOldGC's ParallelTaskTerminator peeks wrong TaskQueueSet

Hi Richard,

On 2016-03-31 15:55, Reingruber, Richard wrote:

Hi,

I would like to contribute a fix for a bug in parallel old gc. The bug can cause long gc pauses, because work stealing while marking does not work as ParallelTaskTerminator peeks the wrong task queue set. A microbenchmark that produces an object graph with large linear parts consistently shows 3x shorter gc pauses with the fix (see bug report). In a similar synthetic test the bug sporadically caused pauses 10x longer than average. Webrev: http://www.sapjvm.com/rr/webrevs/8153176paroldgcwrongtaskqueuesetinmarking/webrev01/

As I mentioned in the bug I think the same problem affects parallel reference processing as well, see RefProcTaskExecutor::execute in pcTasks.cpp.

Another fun thing is that if there are only object arrays on any thread's work stealing queue then work stealing also breaks down, because the terminator doesn't check the _objarray_queues.

Perhaps as a future change ParallelTaskTerminator could be decoupled from TaskQueueSetSuper and instead using either template based polymorphism or virtual calls to do the "peek in queue set" callback.

/Mikael

Bug: https://bugs.openjdk.java.net/browse/JDK-8153176

The change needs to be sponsored as well, please. Thanks, Richard. -- Richard Reingruber | SAP JVM | CORE PLATFORM, SAP SE Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx

More information about the hotspot-gc-dev mailing list