RFR: 8264268: Don't use oop types for derived pointers

Kim Barrett kbarrett at openjdk.java.net
Sun Mar 28 12:02:42 UTC 2021


On Fri, 26 Mar 2021 11:52:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JIT compiler embeds pointers to addresses within an object. These are called derived pointers. When the GC moves objects, these pointers need to be updated explicitly, because the GC only deals with the real oops of the objects (base pointer).
> 
> The code that deals with this uses oop* for the address containing the base pointer. This is fine, the address contains an oop. However, it also uses oop* for the interior pointer, even though the contents is not a valid oop.
> 
> This creates temporary oops that does not conform to the normal requirements for oops. For example, the lower three bits could be set. This makes it problematic to write stricter verification code.
> 
> I propose that we use intptr_t* instead of oop*, and only use oop* when the location is known to contain a valid oop.

I agree with jrose that having a type name for derived pointers would be better.  But I wondered if it might be possible to make it stronger than just an alias type for intptr_t.  I tried making it an enum class with a few supporting operations, and it doesn't look too bad.
https://github.com/kimbarrett/openjdk-jdk/tree/derived_ptr

src/hotspot/share/compiler/oopMap.cpp line 196:

> 194: }
> 195: 
> 196: static void add_derived_oop(oop* base, intptr_t* derived, OopClosure* oop_fn) {

`add_derived_oop` and `ignore_derived_oop` ignore `oop_fn`.  Maybe they should assert that it's `&do_nothing_cl` ?

src/hotspot/share/compiler/oopMap.cpp line 290:

> 288:       intptr_t* derived_loc = (intptr_t*)fr->oopmapreg_to_location(omv.reg(),reg_map);
> 289:       guarantee(derived_loc != NULL, "missing saved register");
> 290:       oop *base_loc = fr->oopmapreg_to_oop_location(omv.content_reg(), reg_map);

`oop *base_loc` -> `oop* base_loc`

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

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


More information about the hotspot-dev mailing list