Yes, verified that reverting to eager initialization of the system image
reader avoids this issue. I guess we need to back this optimization out
and see if we can improve things in the future:
diff -r 32cb9898b630
src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
---
a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
Thu Feb 16 17:05:48 2017 +0100
+++
b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
Thu Feb 16 17:08:12 2017 +0100
@@ -115,12 +115,7 @@
long t0 = System.nanoTime();
// system modules (may be patched)
- ModuleFinder systemModules;
- if (SystemModules.MODULE_NAMES.length > 0) {
- systemModules = SystemModuleFinder.getInstance();
- } else {
- systemModules = ModuleFinder.ofSystem();
- }
+ ModuleFinder systemModules = ModuleFinder.ofSystem();
PerfCounters.systemModulesTime.addElapsedTimeFrom(t0);
/Claes
On 02/16/2017 05:01 PM, Alan Bateman wrote:
On 16/02/2017 14:52, Daniel Fuchs wrote:
:
I don't think this has anything to do with JDK-8173607.
JDK-8173607 just splitted the JMX RMI Connector out of
java.management - and rmid has nothing to do with JMX.
rmid doesn't depend on either java.management or
java.management.rmi, and I don't see anything
on the exception path that would involve either
of these modules.
So I suspect the culprit is probably elsewhere.
Right, this is nothing to do with the JMX changes. I think this is
tickled by the recent change from Claes to create the image reader
lazily. I guess the rmid tests might be disabled because it would have
otherwise been seen before now.
-Alan
