Hi Zeev,
Le 06/09/2017 à 16:01, Zeev Suraski a écrit :
Thanks for the pointer! I didn't pay close attention to that discussion back then. I do remember François brought it up in a discussion back in 2015 in Paris. For me the issue of security is a major benefit that I don't think was brought up in that discussion. It's the killer feature as far as I'm concerned.
Sure. During the discussion, we focused on maintainability but increased security is a key benefit too.
For those who mentioned that PHP code is better managed in Composer - I think we're talking about different layers here. The goal wouldn't be pulling in things from the framework layers into the PHP layer, but being able to surgically replace existing implementations that could benefit from being written in PHP - as well as potentially some very basic non-complex building blocks that change very infrequently if at all. I don't really know, but I'm guessing the challenge experienced by MongoDB probably had to do with the fact this was a pretty big & complex extension as well as one that evolves and changes pretty frequently - the kind of which is probably still better served in C code (or alternatively, a Composer based package).
The discussion made clear that the feature has nothing to do with composer, and I hope everyone now agrees on this.
PCS seems to be a huge step in the direction I think we need to take, although I think we probably need to push it further a couple of notches.
My primary constraint, with PCS, was to implement it as a pure extension, without modifying anything in the core. But the discussion made clear that, when the feature exists, making it optional is useless. That's why I am currently working on a new version, as an extension too, but a mandatory one, included in the PHP core.
First, offhand, I don't think autoloading should play a role. We should create a mechanism where the PHP-based code is at the exact same level as C-based code, i.e., it's available the whole time, including function_exists(), indirect reference and whatnot. In order to achieve that with good performance we probably need to find a way to compile all the different built-in PHP elements in one go so that they fit into one 'virtual include' that can be easily and quickly made available to all requests. I don't think PCS currently supports that, but I'm pretty sure we can achieve that.
I also gave up with the autoloader. If functions could be autoloaded, it could be worth going further, but this is definitely not the right mechanism to base it on.
So, help is welcome here. Currently, my plan is to use opcache to persist the code and load it when needed. I already have the stream wrapper, virtual paths... Combining this with 'fake' function entries should allow to load it just in time. Well, this requires more investigation... Another approach would be to compile the code during MINIT and make it persistent outside of opcache. If you have more ideas about it, they are appreciated.
Secondly, ideally, this shouldn't just be a mechanism to mix and match C and PHP - but actually make it easy for people to write pure PHP code that'll become integrated to the PHP binary. PCS can practically already support that, we'd just need some build magic to take .php files during build, create the PCS wrapper for them and compile them right in. Have some sort of a standard where builtin.php files inside extension directories are included, or something of the sort? Definitely requires more thinking, but if this becomes a basic building block of PHP as I think it should, I wouldn't want end users to have to manually compile PHP code into .phpc or create .c wrappers - but have it as automatic as possible.
Parsing the code, extracting symbol names, and generating all needed information as a C include file is done offline because it requires a working PHP interpreter. So, it cannot be done at build time (when compiling the core). It is done the same way as the core files generated using PHP (like zend_vm_execute.h/zend_vm_opcodes.h): each time, he modifies the PHP code, the developer must regenerate the '.phpc' files. The '.phpc' file will be managed in git and will be included in the source distribution. So, nothing changes for the end user : phpize/configure/make. The same for extensions included in the core: '.phpc' files are included in the source distrib. I'll also probably include this code (re)generation in 'phpize'.
So, the most difficult part, AFAIK, is how to make class and function code persistent, or load it just in time, or a combination of both. The case of constants is more complex and out of scope at this time. I hope I have some times during the next weeks to implement a prototype, at least for functions.
Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
