On Tue, Dec 17, 2024 at 9:34 PM Martin Balao <mba...@redhat.com> wrote:
> 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—. > Hm, that would be nice if JIT could optimize it. Did you have a chance to verify it?
