RFR: 8229773: Resolve permissions for code source URLs lazily

[Sean Mullan]

Hi Claes,

I already reviewed an earlier version of this and this is pretty 
similar. I did have a question about whether the default serialization 
was ok - did you look into that more?

--Sean

On 8/15/19 6:03 AM, Claes Redestad wrote:
> 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