RFR (S/M): 8151069: Parallelize clearing the per-thread concurrent mark data structures

Tom Benson tom.benson at oracle.com
Tue Mar 8 18:29:13 UTC 2016

Hi Thomas,
Looks good.  Just a couple of minor comments/questions.

Should _num_tasks and _cur_task be uint rather than size_t?  It looks 
like task counts/indices are usually uint, such as _max_worker_id, 
_active_tasks, etc.   (That would also let you get rid of the cast to 
uint you added in your other (8151126) change, at 2658 in g1ConcurrentMark).

Can you add a comment on why a task index is being computed rather than 
using worker_id?   I assume it's because, although worker ids cover the 
right range,  you can't guarantee that all worker_id's between 0 and 
number of workers will appear in calls to work().  IE, some workers may 
handle multiple tasks.  Is that correct?


On 3/4/2016 5:01 AM, Thomas Schatzl wrote:
> Hi,
>    clearing the per-thread concurrent mark data structures single
> threaded is a really bad idea since it lenghtens the concurrent mark
> cycle.
> This change parallelizes this work. It is based on JDK-8077144.
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8151069
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8151069/webrev/
> Testing:
> jprt, vm.gc testlist, some applications
> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list