RFR (S): Specialize iteration over marked objects

[Aleksey Shipilev]

D'oh!

I actually first tried to construct something like
ShenandoahMarkObjsClosure<T> that instantiates T implicitly, but then I
gutted the implementation up to the point we could use the templated
methods instead. Silly me.

See the update:

http://cr.openjdk.java.net/~shade/shenandoah/specialize-mark-iterate/webrev.02/

Thanks,
-Aleksey

On 11/04/2016 08:36 PM, Roman Kennke wrote:
> To be honest, it looks a bit overcomplicated to me :-)
> 
> I would think it's enough to make marked_object_iterate() templated:
> 
> template <class T>
>  void marked_object_iterate(ShenandoahHeapRegion* region, T* cl) {
>   ...
>   cl->do_object(obj);
>   ..
> }
> 
> and moved to shenandoahHeap.inline.hpp
> 
> Moving into ShenandoahHeapRegion is ok too, of course.
> 
> Or maybe I'm missing something?
> Roman
> 
> 
> Am Freitag, den 04.11.2016, 20:01 +0100 schrieb Aleksey Shipilev:
>> Hi,
>>
>> Our current ShenandoahHeap::marked_object_iterate does the virtual
>> call
>> to ObjectClosure::do_object for every marked object, for every task
>> out
>> there. When the per-oop work is small, this is not good. Also limits
>> optimizeability (e.g. coalescing ShenandoahHeap::heap(), oopDesc::*,
>> etc).
>>
>> This is the template-based specialization:
>>
>> http://cr.openjdk.java.net/~shade/shenandoah/specialize-mark-iterate/
>> webrev.01/
>>
>> After this change, our work is concentrated in specialized methods,
>> e.g.:
>>
>>    6.90%  ShenandoahMarkObjsClosure<ShenandoahMarkUpdateRefsClosure,
>> false>::do_object_or_array
>>    5.82%  ShenandoahCompactObjectsTask::work
>>    5.51%  ShenandoahPrepareForCompactionTask::work
>>    5.20%  ShenandoahAdjustPointersClosure::do_oop
>>    4.20%  ShenandoahAdjustPointersTask::work
>>    ...
>>
>> (for ShenandoahAdjustPointersClosure::do_oop, inlining breaks
>> elsewhere,
>> to be handled separately)
>>
>> Testing: hotspot_gc_shenandoah, jcstress -m quick, some
>> microbenchmarks
>>
>> Thanks,
>> -Aleksey
>>
>>