Re: Introducing compile time code execution to PHP preloading

Am 14.01.2020 um 20:23 schrieb Mike Schinkel <mike@newclarity.net>: > > 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 >>> a concern I don't see why we could not artificially limit recursion on >>> preload to a configurable amount, with 100 being the default? >> >> 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. >> >> 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. > > class Foo { > preload function bar() { > return < a_really_time_consuming_expression>; > } > } > $foo = new Foo(); > echo $foo->bar(); // This would not actually execute anything at runtime. > // It would simply echo the constant value that was > // returned by <a_really_time_consuming_expression>. > So like this old memoize extension? https://pecl.php.net/package/memoize > > 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. > > 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. >>> >>> The unfortunate problem with PHP is there is no way to use 3rd party >>> code to extend PHP w/o being able to reconfigure the server by adding >>> extensions. It would be nice if we could come up with a way for 3rd >>> party developers writing in C or another language — people who are more >>> likely to test their code before distributing it — to extend PHP such >>> as by generating OpCode files that a userland developer could load. >> >> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >