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