Re: [RFC] Static property asymmetric visibility

Hi Niels On Tue, Jan 7, 2025 at 7:37 PM Niels Dossche <dossche.niels@gmail.com> wrote: > > On 04/01/2025 00:14, Larry Garfield wrote: > >> > >> https://wiki.php.net/rfc/static-aviz > I'm not sure how I feel about this. > The current implementation actually uses a workaround because otherwise it interferes with > cache slot merging. > This creates duplicated code in the VM handlers. Although the complication is small, it still > is one. And the complication may be duplicated in the future in the JIT. > Workarounds/complications can be fine if having the feature is justifiable, but you said > yourself that it seems of little use and the RFC text says it's just for completeness. > So honestly, I'm conflicted and leaning towards voting "no". I wouldn't necessarily call this a workaround, but more of a missed optimization (one branch for each static property write that is unlikely to mispredict). If you wish, I can have a look at separating cache slots. This may lead to a slowdown due to cache priming (as only R/IS and RW/W/UNSET will be shared). To be honest, I doubt either of those will lead to a measurable difference in real code. I can confirm this by running some benchmarks. The benefit of separate cache slots is that it can be entirely handled in zend_fetch_static_property_address(), which would reduce VM/ future JIT changes, although the separation of the cache slots themselves might be more complex (given how it's currently implemented). Ilija