RFR: Avoid evacuating filler objects in Shenandoah

Zhengyu Gu zgu at redhat.com
Thu Aug 31 12:14:20 UTC 2017


I did some performance runs late last night, it showed regression.

Apparently, oop->is_filler() was not cheap, especially testing on marked 
oops, which is not necessary.

I refactored these code paths: 
http://cr.openjdk.java.net/~zgu/shenandoah/sh_filler/webrev.01/index.html

It still failed to show improvement on evacuation time. I suspect we 
over estimated the number of fillers over TAMS.

Therefore, I would like to withdraw this change and re-exam the 
assumption is correct.

Thanks,

-Zhengyu



On 08/31/2017 05:20 AM, Aleksey Shipilev wrote:
> On 08/30/2017 10:55 PM, Zhengyu Gu wrote:
>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/sh_filler/webrev.00/index.html
> 
> We need to do performance study for this first: checking the is_filler flag on marked_object_iterate
> path should be offset by the performance improvements. I did my initial experiments with -Xint to
> only care about native paths. Also, the initial estimate of 5-10% was gathered during full heap scan
> during verification. It may be the case that evacuation does not encounter filler objects all that much.
> 
> Suggestion: revert marked_object_iterate, put p->is_filler() checks on interesting paths in e.g.
> evacuation and see if we indeed take that shortcut. Then, make CollectedHeap::fill_with_array inject
> fillers with either intArray or fillerArray, based on UseNewCode flag, and compare runtime performance.
> 
> Thanks,
> -Aleksey
> 


More information about the shenandoah-dev mailing list