RFC: Parallel deferred updates

[Thomas Schatzl]

Hi,

On 12.08.22 17:42, Nick Gasson wrote:
> Hi Thomas,

   apologies for the late replies (and potentially some in the next 
time), as I'm on and off on vacation right now.

> 
> 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?

During this phase the object's size can be inferred by the bitmaps; 
actually if you look e.g. at psParallelCompact.cpp:2900 it looks like 
that before getting into the "ParMarkBitMap::would_overflow" branch, 
that object's size is already calculated always. (I.e. that object's end 
searched for, only that final size calculation is conditional, but 
that's just a pointer_delta()).

So it looks like we have the object sizes at our disposal after all.

>>
>> 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, would be nice.

Thomas