RFR: 8275527: Separate/refactor forward pointer access

Roman Kennke rkennke at openjdk.java.net
Wed Oct 20 14:17:05 UTC 2021


On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.:
> fwd = obj->forwarded() ? obj->forwardee() : promote_obj();
> 
> or similar constructs.
> 
> Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files).
> 
> I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis.
> 
> Testing:
>  - [x] tier
>  - [x] tier2
>  - [x] hotspot_gc

> Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5)
> 
> and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955)



> Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5)
> 
> and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955)

Thanks! Yes this is indeed better. I will merge into this PR as soon as I get to it.

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

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


More information about the shenandoah-dev mailing list