RFR: 8292177: InitialSecurityProperty JFR event

Sean Coffey coffeys at openjdk.org
Wed Sep 28 10:09:41 UTC 2022


On Tue, 27 Sep 2022 20:29:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:
> 
>> 310:     }
>> 311: 
>> 312:     private static void emitInitialSecurityProperties() {
> 
> Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT.

Good catch. JFR does load the Security class [1] via other dependencies but we shouldn't depend on that. I'll add a null check here. If Security class hasn't been loaded, then we shouldn't record any events.


[1]
java.lang.Throwable
        at java.base/java.security.Security.<clinit>(Security.java:73)
        at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
        at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
        at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
        at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
        at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
        at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
        at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
        at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
        at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
> 
>> 711: 
>> 712:     <event name="jdk.InitialSecurityProperty">
>> 713:       <setting name="enabled">true</setting>
> 
> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.

Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 

We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10394


More information about the core-libs-dev mailing list