<div dir="ltr"><div dir="ltr">On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan <<a href="mailto:xuelei.f@gmail.com">xuelei.f@gmail.com</a>> wrote:<br></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Dec 17, 2024 at 6:45 PM Martin Balao <<a href="mailto:mbalao@openjdk.org" target="_blank">mbalao@openjdk.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan <<a href="mailto:xuelei@openjdk.org" target="_blank">xuelei@openjdk.org</a>> wrote:<br>
<br>
> Not to mention the performance impact.<br>
<br>
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.<br></blockquote><div><br>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.<br></div></div></div></blockquote><div><br></div><div>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—.</div></div></div>