[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] [External] : Re: Which JVMs support eager class loading?
|
On 10/10/22 9:10 AM, Gurunandan Rao
wrote:
IMO, it will be good to consult JDK forums to know on current
JVM support for eager class loading. We can try on JDK
documentation, but not much martial with specifics on JVM
configuration on support for eager class loading is available as
per my knowledge.
Even if we find that there are no JVM implementations using eager
class loading, there still could be a future JVM that uses eager
class loading as it is allowed by the latest JVM
Spec.
Also IMO, would be great if SPEC's highlight their dependency on
JDK security manager if any.
https://docs.google.com/document/d/1m-dkvbL0iFFzitO4vt1SVq6GGSJyFdCDM2NU_FzGS10/edit?pli=1#
mentions the Security SPEC but agreed other will need to do the
same for EE 11.
regards,
Guru
Hi, Scott,
It's very rare that a JVM uses eager
classloading. I don't know much about eager
classloading from my own experience, but my research
shows that, 11 years ago, IBM's JVM supported a JVM
option to turn eager classloading on. I also think
that it's possible to create a classloader that
loads classes eagerly as soon as it finds them in
the import. But I'm not sure if there are some
classloaders out there which would do that. I can't
think of any scenario where such a behavior would
make sense.
So the only solution for eager JVM class
loaders is updating the SPECs to not use the security
manager which is likely to be in the next major release.
If the various TCKs do a service release to
remove the security manager or make it possible to run with
our it, that will be only for the lazy JVM class loaders.
Thanks for the feedback. If anyone knows of
any current JVMs that support eager class loading, please
speak up.
Scott
On 10/7/22 6:33 AM, Scott Marlow wrote:
Does anyone know which JVMs
support eager class loading?
I like to see what happens
when the Java Security Manager classes are
removed from the JVM and the impact on EE 10
applications.
I am pretty sure we will see
ClassNotFoundException on Security Manager
classes but I would like to see a test prove
it.
For background on eager/lazy class loading look
at the JVM SPEC, I think section 5.4 `Linking`
is worth reading:
From
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html
"
5.4. Linking
Linking
a class or interface involves verifying and
preparing that class or interface, its direct
superclass, its direct superinterfaces, and its
element type (if it is an array type), if
necessary. Resolution of symbolic references in
the class or interface is an optional part of
linking.
This
specification allows an implementation
flexibility as to when linking activities (and,
because of recursion, loading) take place,
provided that all of the following properties
are maintained:
-
A
class or interface is completely loaded
before it is linked.
-
A
class or interface is completely verified
and prepared before it is initialized.
-
Errors
detected during linkage are thrown at a
point in the program where some action is
taken by the program that might, directly
or indirectly, require linkage to the
class or interface involved in the error.
For
example, a Java Virtual Machine implementation
may choose to resolve each symbolic reference in
a class or interface individually when it is
used ("lazy" or "late" resolution), or to
resolve them all at once when the class is being
verified ("eager" or "static" resolution). This
means that the resolution process may continue,
in some implementations, after a class or
interface has been initialized. Whichever
strategy is followed, any error detected during
resolution must be thrown at a point in the
program that (directly or indirectly) uses a
symbolic reference to the class or interface.
Because
linking involves the allocation of new data
structures, it may fail with an
OutOfMemoryError
.
"
Scott
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev