Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108128
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <2502e68d-a1bc-41c6-9763-8c0e2ac9e6f4@www.fastmail.com>
Date: Tue, 14 Jan 2020 14:22:38 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A053F3BB-97CC-4CB3-99DE-275438628E8C@newclarity.net>
References: <CAMuFt-6=FaqRpTEvZDtW_OsLmq3R171nDc7wH0D5itJUosMtdQ@mail.gmail.com>
 <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com>
 <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
 <f0a08ad9-abfa-4155-941c-4efd2cf61842@www.fastmail.com>
 <FF6699B7-39E7-4AD7-8FC6-5EE02BBC8E05@newclarity.net>
 <2502e68d-a1bc-41c6-9763-8c0e2ac9e6f4@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Introducing compile time code execution to PHP
 preloading
From: mike@newclarity.net (Mike Schinkel)

On Jan 14, 2020, at 1:10 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>> I get your concern about recursion, but if that kind of issue is =
really=20
>> a concern I don't see why we could not artificially limit recursion =
on=20
>> preload to a configurable amount, with 100 being the default?
>=20
> It's not recursion itself that's an issue.  It's that the behavior of =
the code changes between preload and non-preload contexts in subtle, =
non-obvious ways.
>=20
> I don't mean a recursive function that runs during preload.  I mean if =
a function that runs in a normal request is written recursively, it will =
fail at high recursion levels only if the file it is in was not =
preloaded.  So whether or not foo.php was run through =
opcache_compile_file() changes when and how code in that file will fail. =
 That's the situation we want to avoid like the plague, IMO.

With respect, that feels like you are concerned about some real edge =
cases, and ignoring the probability that most code run during preloading =
would be written bespoke for preloading.

ALSO, I think I may have caused confusion by calling it "preloading."  =
In my mind that meant "run once" vs. "run for each page load" but I =
think you are (rightly) conflating what I have called "preloading" with =
the new preloading feature in PHP 7.4?

What I have been envisioning is a `preload` (or some other) keyword that =
we could apply to functions, methods, and expressions. When `preload` =
modified  functions/methods/expressions are reached during OpCode =
generation, rather than generate a call to runtime code PHP would just =
run the code and then take the return value and generate OpCode for that =
return value.=20

class Foo {
   preload function bar() {
       return < a_really_time_consuming_expression>;
   }
}
$foo =3D new Foo();
echo $foo->bar();  // This would not actually execute anything at =
runtime.=20
                              // It would simply echo the constant value =
that was
                              // returned by =
<a_really_time_consuming_expression>.


I could be wrong but I find it hard to believe the runtime profile would =
be so different in this context as to create problems of the nature you =
are fearing. =20

Maybe someone like Dimitry who understand the OpCode generation process =
could weigh in?


>> I do completely see your points about the AST and most PHP =
developers. =20
>>=20
>> The unfortunate problem with PHP is there is no way to use 3rd party=20=

>> code to extend PHP w/o being able to reconfigure the server by adding=20=

>> extensions. It would be nice if we could come up with a way for 3rd=20=

>> party developers writing in C or another language =E2=80=94 people =
who are more=20
>> likely to test their code before distributing it =E2=80=94 to extend =
PHP such=20
>> as by generating OpCode files that a userland developer could load. =20=

>=20
> That... sounds a lot like the new FFI extension?  Write code in C or =
Rust or anything that can produce a .so file, plug it into PHP, go?

Unless I am misunderstanding, using an .so requires a sysadmin to add an =
extension and update php.ini. Which is a non-starter on hosted sites =
like Pantheon, WPEngine, Kinsta, Pagely, Flywheel, PressLabs and =
similar.

What I was instead calling for what a way to extend PHP that a userland =
developer with no access to php.ini would be able to achieve.

Interestingly, after my above comment I googled and came across this PHP =
extension that can load a compiled Web Assembly (.wasm) file.  Something =
like this in core would be very useful:

https://github.com/wasmerio/php-ext-wasm

-Mike