RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

Hello Claes,

The following code is included in the constructor of our SecurityManager 
implementation, I suspect we may need to add some classes to this list, 
perhaps this is something that needs documenting?

Regards,

Peter.

/* The following ensures the classes we need are loaded early to avoid
      * class loading deadlock during permission checks */
     try {
         checkPermission(new RuntimePermission("setIO"), 
SMPrivilegedContext);
     } catch (ExceptionInInitializerError er){
         Error e = new ExceptionInInitializerError(
         "All domains on stack when starting a security manager must 
have AllPermission");
         e.initCause(er);
         throw e;
     }
     constructed = Security.class != null;

On 15/08/2019 8:03 PM, 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