Hi Aleksey,
JDK-8219414 decoupled CDS and DumpPrivateMappingsInCore. Removing the
#INCLUDE_CDS guard from the definition of ClassLoader::close_jrt_image()
got missed out (My bad! Missed that during the review). So, since
ClassLoader::close_jrt_image() is decoupled from CDS, it might be better
to move the definition of ClassLoader::close_jrt_image() out of the
#INCLUDE_CDS guard and remove the then un-needed #ifndef ZERO guard from
the call to ClassLoader::close_jrt_image(). I think it would also mean
that the assert ClassLoader::has_jrt_entry() in the definition of
ClassLoader::close_jrt_image() would need to be changed to a return if
(!ClassLoader::has_jrt_entry()) -- else the assert would fail for
exploded builds.
Thank you,
Jini.
On 2/22/2019 3:21 PM, Aleksey Shipilev wrote:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8219574
Fix:
diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
+++ b/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 10:51:11 2019 +0100
@@ -1357,11 +1357,11 @@
// called from signal handler. Before adding something to os::abort(), make
// sure it is async-safe and can handle partially initialized VM.
void os::abort(bool dump_core, void* siginfo, const void* context) {
os::shutdown();
if (dump_core) {
-#ifndef ZERO
+#ifndef INCLUDE_CDS
if (DumpPrivateMappingsInCore) {
ClassLoader::close_jrt_image();
}
#endif
#ifndef PRODUCT
JDK-8219414 incorrectly removed INCLUDE_CDS guard, while
ClassLoader::close_jrt_image() is still
only defined under INCLUDE_CDS.
Testing: Linux x86_64 {server, minimal, zero} builds
Thanks,
-Aleksey
