RFR: 8292177: InitialSecurityProperty JFR event [v3]

[Sean Coffey]

On Tue, 11 Oct 2022 12:39:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
>> 
>> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?
>
> Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

My own thoughts here would be that the JFR event system should try and avoid side effects in such areas. If the Security class hasn't been loaded at time of recording, then I'd argue that the number InitialSecurityProperty events should be zero. (which is not possible at the moment since JFR does trigger Security class loading itself anyway)

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

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