RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[David Holmes]

On 10/11/2020 2:34 am, Jorn Vernee wrote:
> On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> 
>>> I agree with Coleen.
>>
>> I'll give this another try, but I think last time I tried this resolution of the class failed when trying to build the JDK, seemingly since it exists in an incubator module, which is not always added to the module graph.
> 
> Ok, I can confirm that moving this to be a well-known class will result in a `java/lang/NoClassDefFoundError: jdk/internal/foreign/abi/ProgrammableUpcallHandler` error while trying to build the JDK. I think this is because the particular class is in an incubator module, which is not always present.

Right ... well-known classes appear to be limited to being in java.base 
module.

> I think we'll have to stick with the lazy resolution instead.

I think this could still be done non-racily during VM startup, after 
module system initialization i.e. between:

  call_initPhase2()
  ...
  call_initPhase3()

in Threads::create_vm. And it could still use the mechanisms in 
systemDictionary to define a global accessor I think, even if not 
initialized with the other "well known" classes. I don't have a good 
mental picture of how all the pieces of this connect in terms of Java 
APIs and VM entry points so these structuring suggestions may, or may 
not make sense. Potentially this could be a future cleanup anyway.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/634
>