RFC: Parallel deferred updates

[Nick Gasson]

Hi Thomas,

Thanks for the feedback.  I've created JDK-8292296 in the JBS for this.

On 11/08/22 17:30 pm, Thomas Schatzl wrote:
>
> Sounds good, although I would make it just a little more complicated:
> maybe it's useful to actually know the number of valid RegionData and
> counting these when they are set to size the number of threads. And/or
> the number of object arrays (of a particular size, e.g. larger than the
> threshold to split them during marking?) as proxy of "lots of work for
> that object crossing the region"/"worth spinning up a thread". (if that
> is possible at all)

One thing we could do is add a shared counter that's incremented
whenever RegionData::set_deferred_obj_addr() is called with a non-NULL
pointer.  That could be used to decide how many threads to use for the
update processing, but it doesn't tell you how many of those have a
large number of embedded oops.  For that you'd need to examine the class
and I'm not sure that's safe to do inside PSParallelCompact::fill_region
- what if the class pointer was spilled into the next region?

>
> While in SPECjbb according to your description it seems fairly clear
> that it is useful to parallelize every time with all resources as
> each/most of these objects cause lots of work, it seems to be
> disadvantageous to spin up lots of threads if there is not.
>
> I would be interested in the Deferred Updates timing changes for the
> other benchmarks. Maybe there is nothing to see here, but idk whether
> you looked only at overall scores for them or did some more detailed
> analysis.
>

OK sure, I can collected more data for benchmarks other than SPECjbb.

--
Thanks,
Nick