On 10/11/2020 2:34 am, Jorn Vernee wrote:
On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee <jver...@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
