RFR: Avoid evacuating filler objects in Shenandoah

[Zhengyu Gu]

specJVM  run on to-gc1 
(http://to-gc1.usersys.redhat.com:8080/job/zgu-specjvm-jdk10/1/console) 
has confirmed that evacuating fillers are rare cases, and not worth the 
effort.

Please be aware, evacuation totals are in KB  while filler sizes are in 
bytes.

Thanks,

-Zhengyu




On 08/31/2017 08:14 AM, Zhengyu Gu wrote:
> 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
>>