RFR: 8315487: Security Providers Filter [v17]

[Xuelei Fan]

On Tue, Dec 17, 2024 at 9:34 PM Martin Balao <mbalao at redhat.com> wrote:

> On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan <xuelei.f at gmail.com> wrote:
>
>> On Tue, Dec 17, 2024 at 6:45 PM Martin Balao <mbalao at openjdk.org> wrote:
>>
>>> On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
>>> wrote:
>>>
>>> > Not to mention the performance impact.
>>>
>>> I am not sure if you mean the performance impact of having to make sure
>>> that the Filter is not set, or the performance impact of having the Filter
>>> disabled. For the latter, there won't be any impact.
>>>
>>
>> I may not agree because the filter checking was inserted everywhere, and
>> the checking will be performance 2 or more times for each service
>> retrieval.  Even if the filter is disabled, the filter checking code is
>> still there.
>>
>
> The calls that you see to ProvidersFilter::isAllowed include a fast-path
> to handle a disabled filter. When the filter is disabled, the
> ProvidersFilter::filter field is null. Because this field is final, it's
> easy for a JIT compiler to remove calls altogether —the rest of
> ProvidersFilter::isAllowed is dead code and the (empty) method can be
> inlined—.
>

Hm, that would be nice if JIT could optimize it.  Did you have a chance to
verify it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20241218/f180dc74/attachment.htm>