On Tue, 27 Sep 2022 20:29:31 GMT, Sean Mullan <mul...@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
