Re: [RFC] Preloading

php.internals

Dmitry Stogov

7 years ago
On Oct 19, 2018 5:20 PM, Sara Golemon <pollita@php.net> wrote: On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmitry@zend.com> wrote:
> I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload >
Overall, big +1. A few questions: 1) "Only classes without unresolved parent, interfaces, traits and constant values may be preloaded." Is this determined at the moment of an individual opcache_compile_file()? Or can mis-ordered includes resolve themselves upon later compiles? e.g. I compile a.php with `class A extends B {}`, then subsequently compile b.php with `class B {}`. The engine has enough information to resolve this, even if it wasn't presented in an ideal order. We try to resolve dependencies among classes in all preloaded scripts, using iterative fixed-point approach. 2) Will we raise warnings explaining why a given class is being deferred from pre-loading to help users understand how to use this correctly? Yes. This is already done. 3) "Preloading may be used as systemlib in HHVM to define “standard” functions/classes in PHP" Presumably the internal APIs will be defined to handle this at the script level already. What stops us from simply ZENDAPIing the proto and letting extensions call it if they want? ((Simple conservatism is an adequate answer, but I'd like to know why it's out of scope)). I didn't understand what you propose. 4) "In conjunction with ext/FFI (dangerous extension), we may allow FFI functionality only in preloaded PHP files, but not in regular ones." Is there any interest in something like HHVM's HNI interface? FFI always sounds nice in theory, but complex types mean that a little bit of glue code is often a plus. Did you see FFI PoC? https://github.com/dstogov/php-ffi Thanks. Dmitry.
> I'll try to fix this in nearest week(s). >
Thank you for everything you do. -Sara

Michael Wallner

7 years ago
On 20/10/2018 15:06, Dmitry Stogov wrote:
> > > On Oct 19, 2018 5:20 PM, Sara Golemon <pollita@php.net> wrote: > On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmitry@zend.com> wrote: >> I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload >>
> 4) "In conjunction with ext/FFI (dangerous extension), we may allow > FFI functionality only in preloaded PHP files, but not in regular > ones." Is there any interest in something like HHVM's HNI interface? > FFI always sounds nice in theory, but complex types mean that a little > bit of glue code is often a plus.
As always when it comes to PHP and FFI I'd like to point out ext-psi [1] which uses a different approach than other PHP FFIs until now. It parses PSI files at startup, which basically are C header files augmented with the PHP userland interface decls, see for example the PSI file for time.h [2] As you can see, marshalling from and to native types has been taken seriously, and while we're capable of recursively unmarshalling e.g. addrinfo structs [3] and handling sqlite callbacks [4] it's still not possible yet for something like curl_easy_setopt. [1] https://github.com/m6w6/ext-psi [2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi [3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70 [3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56 [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt
-- Regards, Mike

Dmitry Stogov

7 years ago
On 10/25/18 10:47 AM, Michael Wallner wrote:
> On 20/10/2018 15:06, Dmitry Stogov wrote: >> >> On Oct 19, 2018 5:20 PM, Sara Golemon <pollita@php.net> wrote: >> On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmitry@zend.com> wrote: >>> I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload >>> >> 4) "In conjunction with ext/FFI (dangerous extension), we may allow >> FFI functionality only in preloaded PHP files, but not in regular >> ones." Is there any interest in something like HHVM's HNI interface? >> FFI always sounds nice in theory, but complex types mean that a little >> bit of glue code is often a plus. > > As always when it comes to PHP and FFI I'd like to point out ext-psi [1] > which uses a different approach than other PHP FFIs until now. > > It parses PSI files at startup, which basically are C header files > augmented with the PHP userland interface decls, see for example the PSI > file for time.h [2] > > As you can see, marshalling from and to native types has been taken > seriously, and while we're capable of recursively unmarshalling e.g. > addrinfo structs [3] and handling sqlite callbacks [4] it's still not > possible yet for something like curl_easy_setopt. > > > > [1] https://github.com/m6w6/ext-psi > [2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi > [3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70 > [3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt > [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56 > [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt > >
hi Michael, You made a great job developing ext-psi. But anyway, I more like my own FFI implementation (at least because it's simpler and it's mine). FFI::load() in conjunction with preloading, would provide functionality similar to PSI files loading on startup. In the future, I would like to push ext/FFI into core and integrate it with JIT (similar to LuaJIT way). In any case, this thread is about preloading, that is interesting by itself. FFI and JIT are the future scope. Thanks. Dmitry.

Victor Bolshov

7 years ago
Just a side question: will the information on preloaded userland classes and functions be available via php --rc / php --rf commands? On Thu, Oct 25, 2018 at 10:42 AM Dmitry Stogov <dmitry@zend.com> wrote:
> > On 10/25/18 10:47 AM, Michael Wallner wrote: > > On 20/10/2018 15:06, Dmitry Stogov wrote: > >> > >> On Oct 19, 2018 5:20 PM, Sara Golemon <pollita@php.net> wrote: > >> On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmitry@zend.com> wrote: > >>> I would like to start discussion on a Preloadng RFC > https://wiki.php.net/rfc/preload > >>> > >> 4) "In conjunction with ext/FFI (dangerous extension), we may allow > >> FFI functionality only in preloaded PHP files, but not in regular > >> ones." Is there any interest in something like HHVM's HNI interface? > >> FFI always sounds nice in theory, but complex types mean that a little > >> bit of glue code is often a plus. > > > > As always when it comes to PHP and FFI I'd like to point out ext-psi [1] > > which uses a different approach than other PHP FFIs until now. > > > > It parses PSI files at startup, which basically are C header files > > augmented with the PHP userland interface decls, see for example the PSI > > file for time.h [2] > > > > As you can see, marshalling from and to native types has been taken > > seriously, and while we're capable of recursively unmarshalling e.g. > > addrinfo structs [3] and handling sqlite callbacks [4] it's still not > > possible yet for something like curl_easy_setopt. > > > > > > > > [1] https://github.com/m6w6/ext-psi > > [2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi > > [3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70 > > [3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt > > [4] > https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56 > > [4] > https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt > > > > > hi Michael, > > You made a great job developing ext-psi. > > But anyway, I more like my own FFI implementation (at least because it's > simpler and it's mine). > > FFI::load() in conjunction with preloading, would provide functionality > similar to PSI files loading on startup. > > In the future, I would like to push ext/FFI into core and integrate it > with JIT (similar to LuaJIT way). > > In any case, this thread is about preloading, that is interesting by > itself. FFI and JIT are the future scope. > > Thanks. Dmitry. > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Best regards, Victor Bolshov

Dmitry Stogov

7 years ago
Yes. --rf/--rc work for preloaded classes/functions. ________________________________ From: Crocodile <crocodile2u@gmail.com> Sent: Monday, October 29, 2018 1:44:08 PM To: Dmitry Stogov Cc: Michael Wallner; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] [RFC] Preloading Just a side question: will the information on preloaded userland classes and functions be available via php --rc / php --rf commands? On Thu, Oct 25, 2018 at 10:42 AM Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote: On 10/25/18 10:47 AM, Michael Wallner wrote:
> On 20/10/2018 15:06, Dmitry Stogov wrote: >> >> On Oct 19, 2018 5:20 PM, Sara Golemon <pollita@php.net<mailto:pollita@php.net>> wrote: >> On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote: >>> I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload >>> >> 4) "In conjunction with ext/FFI (dangerous extension), we may allow >> FFI functionality only in preloaded PHP files, but not in regular >> ones." Is there any interest in something like HHVM's HNI interface? >> FFI always sounds nice in theory, but complex types mean that a little >> bit of glue code is often a plus. > > As always when it comes to PHP and FFI I'd like to point out ext-psi [1] > which uses a different approach than other PHP FFIs until now. > > It parses PSI files at startup, which basically are C header files > augmented with the PHP userland interface decls, see for example the PSI > file for time.h [2] > > As you can see, marshalling from and to native types has been taken > seriously, and while we're capable of recursively unmarshalling e.g. > addrinfo structs [3] and handling sqlite callbacks [4] it's still not > possible yet for something like curl_easy_setopt. > > > > [1] https://github.com/m6w6/ext-psi > [2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi > [3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70 > [3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt > [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56 > [4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt > >
hi Michael, You made a great job developing ext-psi. But anyway, I more like my own FFI implementation (at least because it's simpler and it's mine). FFI::load() in conjunction with preloading, would provide functionality similar to PSI files loading on startup. In the future, I would like to push ext/FFI into core and integrate it with JIT (similar to LuaJIT way). In any case, this thread is about preloading, that is interesting by itself. FFI and JIT are the future scope. Thanks. Dmitry.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Best regards, Victor Bolshov