On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan <xuele...@gmail.com> wrote:
> On Tue, Dec 17, 2024 at 6:45 PM Martin Balao <mba...@openjdk.org> wrote: > >> On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan <xue...@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—.
