Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109959
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: opcache.no_cache prototype: Opcode optimization without caching
Thread-Index: AQHWIBy08PSXTztOe0qZL2sLDSo6BQ==
Date: Sat, 2 May 2020 01:31:09 +0000
Message-ID:
 <DM6PR07MB66186FDB527FDAADF1449FDBF9A80@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ba787404-5cd1-4076-2bc0-08d7ee387dec
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2020 01:31:09.2644
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT191
Subject: opcache.no_cache prototype: Opcode optimization without caching
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
Currently, it isn't possible to enable optimizations without enabling cachi=
ng.=0A=
They should be orthogonal features - it's already possible to cache without=
=0A=
optimization passes (`opcache.optimization_level=3D0`)=0A=
=0A=
I have a prototype implementing this at https://github.com/php/php-src/pull=
/5504 .=0A=
Conceptually, this behaves like opcache.file_cache_only in that it optimize=
s and doesn't use any shared memory, but doesn't actually save or load file=
s.=0A=
I wanted to measure interest in an RFC to add this to PHP, and on what form=
 this should take.=0A=
(I've heard PR discussion is supposed to be for implementation details, so =
I'm also creating an email thread)=0A=
=0A=
Being forced to either enable caching or file_cache_only causes these probl=
ems:=0A=
=0A=
- For file_cache_only, users would be forced to manage the file cache,=0A=
  and users may not be confident in properly handling all potential edge ca=
ses.=0A=
=0A=
  (Running out of disk space, need to clear stale entries, concerns about o=
pcode=0A=
  corruption not being fixed after restarting a process, etc)=0A=
- The shared memory block uses up a lot of RAM when individual PHP processe=
s=0A=
  are known to be long-lived and don't have a common memory address space.=
=0A=
  (e.g. multiple long-lived php scripts managed by something that is not=0A=
  a php script (e.g. `supervisord`, daemons, tools run in the background in=
=0A=
  IDEs, etc). Typical web server uses such as apache share a process space,=
 and would not use no_cache)=0A=
=0A=
  The opcodes are duplicated in shmem, which wastes memory in use cases=0A=
  where they're stored in the cache but never retrieved.=0A=
=0A=
  The default for opcache.memory_consumption is 128M.=0A=
  Even when this isn't used, the virtual memory to track the shared=0A=
  memory(shmem) segment seems to add 2MB extra per **independent** php proc=
ess in=0A=
  "shared memory" segments (depending on OS settings?), reducing the free R=
AM available for other processes.=0A=
=0A=
  (starting a large number of php CLI scripts that sleep() in a loop,=0A=
  `free` (linux program to report free memory) reports that `shared`=0A=
  increases by 2MB per process without opcache.no_cache, but barely increas=
es=0A=
  with opcache.no_cache=3D1=0A=
=0A=
On an unrelated PR https://github.com/php/php-src/pull/5097#issuecomment-57=
6421941=0A=
Dmitry Stogov mentioned that=0A=
=0A=
> Also, it would be great to move optimizer and JIT into core, to make them=
=0A=
> available even without opcode caching.=0A=
=0A=
On the PR itself, Nikita Popov wrote https://github.com/php/php-src/pull/55=
04#issuecomment-622295467=0A=
=0A=
> I like the idea of having optimization without caching,=0A=
> but the way to go about this is definitely moving the optimizer into Zend=
=0A=
> and making it available completely independently of the opcache extension=
.=0A=
> This has been "planned" for a long time, but never actually happened.=0A=
=0A=
- I think that creating a new setting along the lines of opcache.no_cache w=
ould have a use case before and after such a refactoring,=0A=
  providing the benefits I mentioned for the use cases in the PR descriptio=
n.=0A=
  This would continue to be have a use case even if the caching parts of op=
cache.so moved into php's core=0A=
  (e.g. if that was done, and the caching module were loaded in php.ini=0A=
  as zend_extension=3Dopcache.so, there'd still be a use case for a configu=
ration setting to override that default=0A=
  to disable caching for running individual programs)=0A=
=0A=
  Users may strongly prefer for `opcache.enable`, `opcache.enable_cli`, and=
 `opcache.optimization_level` to continue controlling whether optimizations=
 are performed=0A=
  (so setting the combination of `opcache.enable=3D1`, `opcache.enable_cli=
=3D1`, and a setting such as `opcache.no_cache=3D1` to optimize without cac=
hing would make sense there)=0A=
- If nobody's currently planning to work on moving the optimizer into Zend =
(i.e. into php's core),=0A=
  then it may be several minor releases before it's possible to have optimi=
zation without caching.=0A=
- There may be unforeseen objections to moving the optimizer into Zend from=
 creators/users of profiling tools, debuggers, code coverage tools, etc.=0A=
  Hopefully not, but that'd depend on the proposed implementation details.=
=0A=
=0A=
Thanks,=0A=
- Tyson=