> On Jan 13, 2017, at 7:30 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 1/12/17 3:53 PM, Mandy Chung wrote: >> >>> On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petc...@oracle.com> >>> wrote: >>> >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures >>> that the resources are loaded earlier. >> >> This seems a reasonable approach. There is a slight overhead for >> this change when the resource bundle is never used but it’s not an >> issue since the initialization of a security manager is not cheap >> anyway. >> >> It may be helpful to add a check to ensure that the resource bundle >> is loaded either VM.isBooted() or initLevel != 3. It would make it >> clear of this circular bootstrapping issue. >> >> You do this in SecurityManager class initialization. Have you >> considered doing it in the SecurityManager constructor? As Claes >> clarified, SM is loaded but not initialized during early VM startup. >> So no issue to do it in clinit. The alternative is to do it in the >> constructor as lazy initialization. > > I don't see any particular performance advantage of moving it to the > constructor. The SM will be initialized and instantiated in phase 3 before it > initializes the system classloader. Did you have another concern in mind? >
No. There isn’t any performance difference since such code is invoked when a security manager is created. I’m okay to push this as is. Perhaps you can look into it as part of JDK-8055206 since JDK-8055206 has the initialization code too. Mandy
