RFR (S/M): 8151069: Parallelize clearing the per-thread concurrent mark data structures
tom.benson at oracle.com
Tue Mar 8 18:29:13 UTC 2016
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:
> clearing the per-thread concurrent mark data structures single
> threaded is a really bad idea since it lenghtens the concurrent mark
> This change parallelizes this work. It is based on JDK-8077144.
> jprt, vm.gc testlist, some applications
More information about the hotspot-gc-dev