RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6]

[Ioi Lam]

On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> I think this is already done:
>> 
>> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. 
>> 
>> https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300
>
> I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception?
> 
> If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `<clinit>` method.
> 
> Classes are able to create an instance in `<clinit>` and escape it to other code and then fail initialization.  The instances are left in an odd state where after the `<clinit>` the instance methods can be called but static fields and static methods can't be accessed.
> 
> `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `<clinit>` behaviour.  It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls

Thanks for catching this. I added code to exit the JVM when `runtimeSetup()` fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1828549749