Propoal: PHP C standard function Code usage/porting

[avierr]

It was previously mentioned here https://github.com/abertschi/graalphp/issues/57#issuecomment-699504478 on how to use or implement PHP functions in Graal,

Integration of PHP's native libraries. I see JPHP follows an approach which re-implements many libraries.

 I believe an approachwhich reuses and integrates existing libraries is more viable. This depends on how efficiently these libraries can be integrated and needs to be further evaluated. 

I see @chrisseaton blogged about what they have done with truffleruby some years ago: https://chrisseaton.com/truffleruby/cext/. This sounds very interesting. 

One approach is using re-implementing the PHP function in Java, I am slightly in favour of this approach as it brings some other major IO related real world performance benefits with the combination of https://openjdk.java.net/jeps/353 and http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html. The obvious downside being the time taken to re-implement those methods. There are good transpilers available these days to do most of the heavy lifting though.

The second option is going the route that is described here https://chrisseaton.com/truffleruby/cext/ , There is no source code made available and hence difficult to see how complicated, practical or time consuming this would be when applied to a large project like PHP.

The third option which I would propose is,

1. First we compile PHP source using Clang(LLVM) not to machine code but to intermediate bit code
2. Graal/Sulong[1] is capable of taking in Clang(LLVM) bit code.
3. Graal is capable of optimizing this bitcode
4. Expose this to our PHP interpreter
5. bitcode files will be used for doing more FFI (https://jolicode.com/blog/php-7-4-ffi-what-you-need-to-know)

How easy is all this? See the video for yourself, https://youtu.be/zvsR90T_4ME?t=255 (it covers the first three points)

The obvious drawback would be the IO performance, if I can make an assumption that Graal/Sulong cannot inject instructions for co-operative scheduling.

Any feedback is appreciated 🙂

[1] https://github.com/oracle/graal/tree/master/sulong

[avierr]

ok looks like chris has gone the similar way too: (Feels like a pat on my back) https://chrisseaton.com/rubytruffle/llvm-cauldron-16/llvm-cauldron-sulong.pdf

[avierr]

Sulong lets you virtualise C - so you could intercept calls to the write syscall and redirect them into Java IO calls that work with Loom. There's a version of Sulong that is called 'managed' that does this but I think it's Enterprise only.

-- Chris (Messaging him on twitter)

[abertschi]

One of the next steps is to write proof of concepts to demonstrate feasibility of different ideas and evaluate efficiency of different approaches.

One approach is using re-implementing the PHP function in Java, I am slightly in favour of this approach as it brings some other major IO related real world performance benefits with the combination of https://openjdk.java.net/jeps/353 and http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html. The obvious downside being the time taken to re-implement those methods. There are good transpilers available these days to do most of the heavy lifting though.

For instance, can you demonstrate that a transcompiler approach works well? I doubt that such approach will result it having less engineering efforts. Idiomatic PHP code is not idiomatic Java code and one would end up making many manual modifications in code, given that PHP libraries make use of Zend Engine internals (function argument processing for instance). But you may know better and demonstrate the opposite. If you look at the size of popular bulit-in libraries by the Zend Engine, re-implementing leads to much work, which is not very interesting and hard work.