> On Jan 7, 2015, at 2:18 AM, Pierre Joye <pierre....@gmail.com> wrote:
>> That's very much the case. One extension, one "install". It doesn't
>> matter whether some of the extension is written in C, and other parts in
>> PHP. HHVM is *all* about this. Making use of C where you need it, and
>> otherwise just write the simpler *but integral* border functionality in
>> PHP for faster maintenance and development.
>
> It is not correct nor relevant to compare hhvm extension development with
> this case. With hhvm it ends up with an actual native extension while here
> it is proposed to bundled script that will be executed at runtime like any
> other script, except that nothing can be done with them, not even disable
> them if not required (like using its own glue codes).
Both HHVM and its' extensions embed PHP source in the binaries.
In our experience:
+ bundling them together makes it much quicker to iterate and improve
extensions.
+ the PHP code tends to use ‘non-public’ parts of the C API - so it really
needs to be kept in sync with the PHP version. I’m not sure if composer
currently supports ‘if I’m on PHP 5.6.0 use this library, if I’m on 5.6.1 use
this library…’. While this is fixable, it seems like a lot of boilerplate.
+ If PHP7 does develop a JIT, the PHP implementations could be faster than
calling the C code (type specializing, and the overhead of setting up the stack
for a C function call). This is often the case for HHVM.
- we currently do not support extension-style parameter coercion in PHP
functions; this leads to small incompatibilities in our case, which we usually
address by writing a C++ function that proxies to a hidden PHP implementation.
For PHP7, if the current scalar types RFC lands, this won’t be a problem; if it
doesn’t, there’s a chance that multiple functions from the same extension will
have confusingly different parameter coercing behavior, depending on the
author’s rigor.
We solved some of the other problems by only allowing definitions, no
side-effects - classes, constants, namespaces etc. We do not allow code outside
of a function body here.
HHVM-specific details (just FYI, agree that they’re probably not particularly
relevant):
* We do not translate the PHP source to native code (unless it ends up being
jitted at runtime)
* We’re planning on supporting the extension-style coercion in Hack code with a
user attribute
* To dig the code out:
$ objdump -h hhvm | egrep ‘ (ext|systemlib)’ # also works for a dynamic
extension .so
…
149 ext.ff104b2dfab9 00002410 0000000000000000 0000000000000000 02d350a5
2**0
150 systemlib 000766a2 0000000000000000 0000000000000000 02d374b5 2**0
$ objdump -s -j systemlib hhvm | head -n 20
hhvm: file format elf64-x86-64
Contents of section systemlib:
00000 3c3f6868 0a2f2f20 7b407d67 656e6572 <?hh.// {@}gener
00010 61746564 0a0a6e61 6d657370 61636520 ated..namespace
00020 7b0a0a2f 2f206465 6661756c 74206261 {..// default ba
00030 73650a63 6c617373 20737464 436c6173 se.class stdClas
00040 73207b0a 7d0a0a2f 2f207573 65642069 s {.}..// used i
00050 6e20756e 73657269 616c697a 65282920 n unserialize()
00060 666f7220 756e6b6e 6f776e20 636c6173 for unknown clas
00070 7365730a 636c6173 73205f5f 5048505f ses.class __PHP_
00080 496e636f 6d706c65 74655f43 6c617373 Incomplete_Class
00090 207b0a20 20707562 6c696320 245f5f50 {. public $__P
000a0 48505f49 6e636f6d 706c6574 655f436c HP_Incomplete_Cl
000b0 6173735f 4e616d65 3b0a7d0a 7d0a0a6e ass_Name;.}.}..n
000c0 616d6573 70616365 207b0a0a 2f2f2055 amespace {..// U
000d0 73656420 61732061 2073656e 74696e65 sed as a sentine
000e0 6c207479 70652069 6e203836 70696e69 l type in 86pini
000f0 7428292e 0a636c61 7373205f 5f70696e t()..class __pin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
