Withdrawn: 8270554: Shenandoah: Optimize heap scan loop

[duke]

On Thu, 15 Jul 2021 14:37:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is a fall-out from Lilliput. I noticed that in the heap scan loop, we load the size of objects in the size-based object scanner, even though all of the object closures already load the size, or at least in some cases, the Klass* which is necessary to determine the size. We can optimize that by making the scan loop co-operate with the closures. In other words, this changes the loop to avoid double-loading the Klass* in most cases in the size-based part of the scan loop.
> 
> Note: the motivation in Lilliput is not performance, but correctness, because there loading the Klass* means loading the header, and this needs to be done carefully because of concurrent evacuation and concurrent locking code both messing with the header, and thus depends a lot on the actual closures to do it correctly. 
> 
> Implementation notes:
> - SH::evacuate_object() has been changed so that it can return both the forwardee and the size. I opted to return the size as return-value because otherwise I'd have to null check an incoming pointer in the cases when we're not interested in the size. The way it is done, it can simply be ignored (and optimized-out) by the compiler.
> - I added a do_object_size() variant to all affected iterators. I tried to do it with templates, but could not figure out how to please the compiler.
> - While I was at it, I marked all do_object() methods as 'inline'.
> - I ran some benchmarks. I think I see consistent but small improvements in evac and update-refs times, but it's not large enough to say that it is a definite improvement.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 (+UseShenandoahGC)
>  - [x] specjvm testing

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4797