Hey Go,
On 16.5.2026 17:19:31, Go Kudo wrote:
Hi internals,
I'd like to start the discussion for a new RFC, OPcache Static Cache.
RFC: PHP: rfc:opcache_static_cache
Implementation: [RFC] OPcache Static Cache Implementation by zeriyoshi · Pull Request #22052 · php/php-src · GitHub
The proposal adds an OPcache-managed shared-memory cache for explicit userland values and for selected PHP static state. It introduces explicit functions under the OPcache namespace (volatile_* and persistent_*) and two attributes, #[OPcache\VolatileStatic] and #[OPcache\PersistentStatic], that let selected static properties and method static variables survive across requests. The feature is disabled by default and only activates once memory is allocated through the new INI directives.
The RFC covers the motivation, the deliberate split between the two backends, the trust model (one PHP runtime = one trust domain; this is not a tenant isolation boundary), and benchmarks against APCu on NTS php-fpm and ZTS FrankenPHP. The PR is the full implementation, with PHPT coverage summarized in the Validation section.
Feedback welcome.
Best Regards,
Go Kudo
I've been trying to digest the RFC and it's quite long-winded.
The one thing I don't grasp is the "Security and Trust Model". Sure, if you have the worker pools, like in fpm, it absolutely makes sense to use it.
But why is it fundamentally required to have this sort of separation? What's the point? It just means that the whole webserver is a single boundary rather than having the ability to split more precisely. Which in the end is a configuration / system administration setup issue, rather than a fundamental flaw.
To me it's a non-starter to exclude apache2handler SAPI from this feature.
Regarding the API:
I think it might make sense to make the caches non-static classes, with a constructor accepting an optional arbitrary namespace; further split the overloaded behaviour of delete() and getCacheStoreType() - let's not mix classes and arbitrary keys:
abstract class Cache {
public abstract function get(string $key, null|bool|int|float|string|array|object $default = null): null|bool|int|float|string|array|object;
public abstract function getMultiple(array $keys, ?array $default = null): array|false;
public abstract function set(string $key, null|bool|int|float|string|array|object $value): bool;
public abstract function setMultiple(array $values): bool;
public abstract function has(string $key): bool;
public abstract function delete(string $key): bool;
public abstract function deleteMultiple(array $keys): bool;
public abstract function clear(): bool;
public abstract function lock(string $key, int $lease = 0): bool;
public abstract function unlock(string $key): bool;
public static function clearClass(string $class_name): bool;
public static function getCacheStoreType(string $key): CacheStoreType;
public static function getPropertyCacheStoreType(string $class_name, string $property): CacheStoreType;
public abstract static function clearAll(): bool;
public abstract static function info(): StaticCacheInfo;
}
class VolatileCache extends Cache {
public function __construct(string $namespace = "");
// Note that set() and setMultiple() are redeclared with optional `int $ttl = 0` parameters
public function set(string $key, null|bool|int|float|string|array|object $value, int $ttl = 0): bool;
public function setMultiple(array $values, int $ttl = 0): bool;
public static function clearAll(): bool;
public static function info(): StaticCacheInfo;
}
class PinnedCache extends Cache {
public function __construct(string $namespace = "");
public function increment(string $key, int $step = 1): int|false;
public function decrement(string $key, int $step = 1): int|false;
public static function clearAll(): bool;
public static function info(): StaticCacheInfo;
}
Given that the API is nearly identical, we can simplify it for both cache types and any library which actually requires $ttl can explicitly require VolatileCache instead of PinnedCache - with just $ttl being different.
An *application* author who does not want to carry around an instance of the caches, can trivially write define('VOLATILE', new VolatileCache); once and write VOLATILE->get("mykey") everywhere, getting the same usability than Volatile::get("mykey"), essentially.
This will allow you to inject well-scoped caches (instead of relying on the libraries to prefix their keys), declare new cache impls (e.g. "class LocalCache extends Cache", which would just do request-local caching rather than actually storing it) and make it easy to select between PinnedCache and VolatileCache as a library user.
I'm pretty confident this is what a lot of people here want to actually have, API wise.
Regarding atomic increment/decrement: does it actually matter that volatile does not guarantee continuity?
The behaviour of missing key is well-defined. I consider it much better to provide it than have users create their own poor-mans counter of get() + set() combination.
Also, a counter on a VolatileCache may actually be useful - e.g. the counter dropping back to zero is an indicator that eviction started. I would not assume this useless. Less useful than a counter of a PinnedCache, yes, but omitting it from VolatileCache is too opinionated.
Regarding Storable values: why are Closures not storable? The RFC says:
"Closure objects are request-local executable state and cannot be represented as stable shared cache values"
But that's not quite true - all Closures, except for those from non-file inclusions, like eval(), are effectively available in opcaches shared memory. And those which are not, could technically be stored too - might be a bit more expensive, but it's seldom the case. Would need some custom serialization though. Not supporting them is a choice, but the reason ("cannot") is the wrong one.
Regarding Attributes: Ah, the big contentious topic?
I'm not sure what to make of them. I get the appeal of a nice attribute that makes it just work, but it's limited, in sort of subtle ways:
- Refreshing the values ... is impossible? The RFC text says manually going through the Volatile/PinnedCache APIs with the 'volatile_static_class:' prefix and such is disallowed?
- Do we actually need to reserve these (*_static[_class]
prefixes? Can't we keep this an implementation detail and make sure that there are dedicated API methods to properly handle it?
- Why do we need dedicated prefixes? (volatile_ and pinned_, that is) Can't we look the specific class / property up and derive the required cache internally?
- The tracking implementation works by adding a tracking callback to the hot path of every array modification. Minor, but noticeable cost if nothing uses these attributes. Significant cost if attributes are used. Even more significant if writes are alternating (i.e. subsequent writes access different arrays). That's a total non-starter. Maybe you could do some hackery with overloading RW access to static properties specifically to assume dirtied. But the current implementation is a no-no. I get that this also affects stored objects and such. But, as said, too invasive/expensive.
I really wonder whether you sat down at any point here and asked yourself "should I really do this?", given all its complexity here.
- Scalar values are also not auto-refreshed, which probably makes for surprising behavior when trying to increment some counter, and other requests increment in parallel. I'm not too happy about the developer experience around this.
Overall, the attributes probably need quite a bit more discussion and refinement. I think it might be worth splitting it fully off into its own RFC.
And the implementation will be probably also downsized by more than half, making it a bit more manageable to review and assess.
The general integration of APCu-like capabilities with separate pinned and volatile caches make a lot of sense to me.
With some minor refinements, I think I'd like to see this functionality in PHP!
Thanks for your effort on this RFC,
Bob