Hi, by resolving permissions for code source URLs lazily, we can reduce early class loading during bootstrap, which improves footprint, startup and reduces the typical bootstrap dependency graph.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ A note on the System.java changes: The laziness makes it so that FilePermission isn't initialized eagerly, which has an implicit bootstrap dependency on that the default file system provider has been initialized before a SecurityManager has been installed (since initializing FilePermission will otherwise do recursive calls into FilePermission). We already force load of the image reader on SecurityManager due similar bootstrap issues, which transitively loads the DefaultFileSystemProvider.instance(), but explicitly adding the dependency on the file system provider to System::setSecurityManager seems prudent: it's effectively a no-op on jdk/jdk right now, but documents the dependency and safeguards against future implementation changes to image reader subsystem. A note on the HelloClasslist changes: The patch drops a number of classes from being loaded on typical bootstrap and small apps, including the HelloClasslist tool. Since the HelloClasslist establishes what's to be included in the default CDS archive this can lead to a small regression on apps which actually do use the (nio) file system provider, so explicitly adding it in avoids tiny regression on those while not diminishing the speed-up to other apps. Testing: tier1-3 Thanks! /Claes
