Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130916
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 16 May 2026 15:13:36 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <b1f920f5-f219-4957-a599-fd177de870db@app.fastmail.com>
In-Reply-To: 
 <CABTDVhBhT5OVGfMV7eZZs6Ysuu0ggcDYkmUHP6v1eTnVdwD6tQ@mail.gmail.com>
References: 
 <CABTDVhBhT5OVGfMV7eZZs6Ysuu0ggcDYkmUHP6v1eTnVdwD6tQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] OPcache Static Cache
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, May 16, 2026, at 10:19 AM, Go Kudo wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC, OPcache Static Cache.
>
> RFC: https://wiki.php.net/rfc/opcache_static_cache
> Implementation: https://github.com/php/php-src/pull/22052
>
> The proposal adds an OPcache-managed shared-memory cache for explicit=20
> userland values and for selected PHP static state. It introduces=20
> explicit functions under the OPcache namespace (volatile_* and=20
> persistent_*) and two attributes, #[OPcache\VolatileStatic] and=20
> #[OPcache\PersistentStatic], that let selected static properties and=20
> method static variables survive across requests. The feature is=20
> disabled by default and only activates once memory is allocated throug=
h=20
> the new INI directives.
>
> The RFC covers the motivation, the deliberate split between the two=20
> backends, the trust model (one PHP runtime =3D one trust domain; this =
is=20
> not a tenant isolation boundary), and benchmarks against APCu on NTS=20
> php-fpm and ZTS FrankenPHP. The PR is the full implementation, with=20
> PHPT coverage summarized in the Validation section.
>
> One thing to flag on the implementation status: the Windows build is=20
> currently broken. I don't have a Windows development environment=20
> available yet =E2=80=94 one is being arranged through work, and I'll g=
et the=20
> Windows side fixed once that's in place.
>
> Feedback welcome.
>
> Best Regards,
> Go Kudo

Interesting!  I can definitely see uses for it, and I appreciate the lev=
el of detail in the RFC.

Some thoughts, though:

- atomic-decrement throwing if a value doesn't exist sounds like a footg=
un.  For something like an up/down voting widget, I could very easily se=
e someone hitting the Down Vote button first, which would cause it to cr=
ash.  Having to always check _exists() on decrement but not on increment=
 is inconsistent and likely to confuse people.

- Are either of these stores purged on reboot? =20

- "persistent cache and returns void on success." - No, returns null.  Y=
ou can't return void.  A function can have a void return type, whether i=
t's successful or not.  Not quite the same thing.

- Having the locks automatically self-unlock sure sounds elegant at firs=
t, but the lack of symmetry in the API feels very error prone.  People w=
ill want to use it like a transaction, but since it unlocks on the first=
 write there's no way to make it one.  It just silently unlocks if certa=
in functions are called.  But if they're not called, there's no way to u=
nlock it.  That's even more of an issue in a persistent-process use case=
, where you could easily not hit the process-end for minutes or hours, s=
o the lock never automatically clears.

Use case: You need to update some lookup table, so you lock the stored k=
ey, compute the new table, then write the new table.  But if the compute=
 step fails for some reason, you now have a locked value with no way to =
unlock it, but no new value to write to it.  It's better in many cases t=
o leave the stale data there rather than delete it, but this API doesn't=
 offer a way to do that.

- It's not made clear: Do objects have their __serialize() methods calle=
d when storing (and vice versa on load), or no?  "They have to be serial=
izable" is not something that can be otherwise determined.

- Status API: Uh, what are the keys?  No arrays here please.  Please mak=
e it an object with defined readonly properties.  Please.

- You realize you're effectively adding a Memoize attribute to PHP by an=
other name, right?  Just making sure. :-)

- A property using the volatile-tracking strategy, if run in a persisten=
t process, seems like it would never get written.  That feels like a pro=
blem.

- The section on write times is rather abstract and academic, so a bit h=
ard to follow.  If I read correctly, though, it means that writing to a =
sub-property of an array/object on a cached property won't trigger a res=
ave?  That feels like another footgun waiting to happen.

- It's not clear if there's a way to clear an attribute-cached value oth=
er than nuking the entire volatile/persistent cache.  Is there not?  It =
feels like there should be one...  Especially for "persistent," I don't =
want to have to nuke my entire "persistent" cache from orbit because one=
 value got corrupted somehow.

- Defaulting off... I can see the argument for that, but that means it w=
ill be off for most users.  That means I, as a library author of, say, a=
 routing system or a DI container, cannot use it, because I have to assu=
me most users won't have it.  That kneecaps the usefulness of this featu=
re dramatically.  I would strongly recommend setting at least some defau=
lt-on amount, even if it's only the minimum 8 MB, if we want this featur=
e to actually be used.  (And I can already think of a few places where I=
'd want to use it myself.)

- Related, what happens if they're disabled but someone tries to use thi=
s functionality?  Does it operate like every read is a cache miss, or do=
es it error?  If the latter, that means any code that uses the attribute=
s REQUIRES that the ini directives be turned on.  We generally try to av=
oid this kind of "your code may or may not work depending on ini setting=
s" issues.  (Hello, magic_quotes!)

- What's the development experience with this?  Frequently, in dev mode =
frameworks will disable caches.  If the volatile cache just misses silen=
tly that would work there, but not for the persistent cache.  How would =
I have a persistent route cache that is automatically rebuilt on every r=
equest during development while I'm messing with routes?

- I understand the value of keeping it simple by making it single-tenant=
.  However, I can very easily see different 3rd party libraries wanting =
to make use of the cache at the same time.  That poses a risk of key-spa=
ce collision, though that's resolvable by a convention to use a key pref=
ix.  What it does not resolve is cases where one library wants to wipe-a=
nd-rebuild a dynamic list of keys, but some other library isn't expectin=
g a total purge.  There's a high risk of libraries stepping on each othe=
r here.

- Currently, this is just a basic key/value store.  That's great for man=
y things, but not very queryable.  This is absolutely scope creep, but w=
ould there be some way to extend this (in a future RFC, I'm sure) to all=
ow, say, a persistent memory-resident SQLite database?  Currently you ca=
n write one to disk, but then you have to deal with disk permissions.  A=
 memory resident database now is request-specific, so not useful outside=
 of testing.  It would be lovely if there were some way to extend in tha=
t direction.

--Larry Garfield