RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v6]

Doug Simon dnsimon at openjdk.org
Wed Dec 7 19:33:05 UTC 2022


On Wed, 7 Dec 2022 18:42:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - formatting to avoid very long lines [skip ci]
>>  - removed debug code [skip ci]
>>  - clarify Properties filtering [skip ci]
>>  - remove debug code [skip ci]
>
> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:
> 
>> 126:         // Try create with reflection first.
>> 127:         try {
>> 128:             Class<?> cls = Class.forName(className);
> 
> A question about the Class.forName usage here. Class.forName uses the defining class loader of the current class so I'm wondering if the exceptions to be decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is defined to the boot loader so this code hasn't really changed, it's just "new" to java.base in this PR.

The exceptions can be of any type and defined by any loader. In the case that Class.forName fails, the name of the original exception type is shown as part of `TranslationException.toString()`. Combined with the stack trace, this has always been sufficient to understand the origin of an exception thrown on a HotSpot/libjvmci mixed stack.

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

PR: https://git.openjdk.org/jdk/pull/11513


More information about the core-libs-dev mailing list