On 2/27/20 10:14 PM, Calvin Cheung wrote:
Hi Ioi,
On 2/27/20 8:22 PM, Ioi Lam wrote:
Hi Calvin,
This looks good to me.
Thanks for taking another look.
I would suggest adding the something like this to the test case:
class Child extends Parent {
int get() {return 2;}
int dummy() {
// When Child is linked during dynamic dump (when the VM is
shutting
// down), it will be verified, which will recursively cause
Child2/Parent2
// to be loaded and verified.
// We want to make sure that this is done at a point in the
VM lifecycle where
// it's still safe to do so.
Parent2 x = new Child2();
return x.get();
}
}
The following updated webrev includes the above changes in the test case:
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/
Looks good. Thanks!
- Ioi
thanks,
Calvin
Thanks
- Ioi
On 2/27/20 4:48 PM, Calvin Cheung wrote:
Hi David, Ioi,
Thanks for your review and suggestions.
On 2/26/20 9:46 PM, Ioi Lam wrote:
On 2/26/20 7:50 PM, David Holmes wrote:
Hi Calvin,
Adding core-libs-dev as you are messing with their code :)
On 27/02/2020 1:19 pm, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232081
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/
The proposed changeset for this RFE adds a
JVM_LinkClassesForCDS() function to be called from
java/lang/Shutdown to notify the JVM to link the classes loaded
by the builtin class loaders. The
This would be much less disruptive if this was handled purely on
the VM side once we have started shutdown. No need to make any
changes to the Java side then, nor jvm.cpp.
Hi David,
To link the classes, we need to be able to run Java code -- when
linking a class X loaded by the app loader, X will be verified.
During verification of X, we may need to load additional classes
from the app loader, which executes Java code during its class
loading operations.
We also need to handle all the exit conditions. As far as I can
tell, an app can exit the JVM in two ways:
(1) Explicitly calling System.exit(). This will call
java.lang.Shutdown.exit() which does this:
http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163
beforeHalt(); // native
runHooks();
halt(status);
(2) When all non-daemon threads have died (e.g., falling out of the
bottom of HelloWorld.main()). There's no explicit call to
System.exit(), but the JVM will proactively call
java.lang.Shutdown.shutdown() inside
JavaThread::invoke_shutdown_hooks()
http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331
http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184
If we want to avoid modifying the Java code, I think we can
intercept JVM_BeforeHalt() and JavaThread::invoke_shutdown_hooks().
This way we should be able to handle all the classes (except those
that are loaded inside Shutdown.runHooks).
I've implemented the above. No changes to the Java side.
updated webrev:
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/
I also updated the test to test the shutdown hook and System.exit()
scenarios.
All appcds tests passed on my linux host. I'll run more tests using
mach5.
thanks,
Calvin
What do you think?
- Ioi
Thanks,
David
MetaspaceShared::link_and_cleanup_shared_classes() has been
modified to handle both static and dynamic CDS dump. For dynamic
CDS dump, only classes loaded by the builtin class loaders will
be linked. Local performance testing using javac on
HelloWorld.java shows an improvement of >5%.
Passed tier1 - 4 tests.
thanks,
Calvin