[lworld] Integrated: 8280006: [lworld] Compiler interface uses wrong class loader when looking up field type

Tobias Hartmann thartmann at openjdk.java.net
Thu Jan 20 07:35:10 UTC 2022


On Wed, 19 Jan 2022 08:24:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In the test, the primitive type `ValueOnBootclasspath` of flattened `Wrapper1.field` and the type `MyClass` of its flattened `field` are loaded by the boot classloader (`loader` is NULL):
> 
> <ciInlineKlass name=ValueOnBootclasspath loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,final,super super=java/lang/Object ident=1288 address=0x00007f5108540288>
> <ciInstanceKlass name=MyClass loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,super ident=1292 address=0x00007f5108541160> 
> 
> 
> During JIT compilation, when the type of `Wrapper1.field` is computed in `ciField::compute_type_impl()`, `Wrapper1` is used as the holder klass and therefore its class loader (`loader=0x000000062c754858`) is used as context for the lookup:
> 
> 
> <ciField name=TestBootClassloader$Wrapper1.field signature=LMyClass; offset=12 type=(reference) flags=0010 is_constant=true is_flattened=false is_null_free=false>
> <ciInlineKlass name=TestBootClassloader$Wrapper1 loader=0x000000062c754858 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,final,super super=java/lang/Object ident=1284 address=0x00007f510853f440>
> 
> 
> But since `MyClass` was loaded by the boot classloader, the lookup via the application class loader fails and leads to an unloaded klass:
> 
> <ciInstanceKlass name=MyClass loader=0x000000062c754858 loaded=false ident=1289 address=0x00007f5108540708>
> 
> 
> C2's type system then gets confused when mixing both `MyClass` types and bails out with `COMPILE SKIPPED: Can't determine return type. (retry at different tier)`.
> 
> The fix is to use the "original holder", i.e., the klass that defined the field in the source code and not the one that contains it at runtime due to flattening, for the lookup instead.
> 
> While debugging, I also noticed that loading of signature classes before JIT compilation does not apply to fields that came in through flattening. I filed [JDK-8280230](https://bugs.openjdk.java.net/browse/JDK-8280230) to investigate this separately.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: ab46c224
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ab46c224d70c4e605cdd648e5654ead28df33eed
Stats:     192 lines in 6 files changed: 185 ins; 0 del; 7 mod

8280006: [lworld] Compiler interface uses wrong class loader when looking up field type

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/606



More information about the valhalla-dev mailing list