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?
Thanks,
Tom
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