V8Js

Yesterday @dzuelke poked me to migrate the old PHP buildpack adjusted for V8Js to the new custom platform repo infrastructure. The advantage is that the custom platform repo only contains the v8js extension packages now, the rest (i.e. Apache and PHP itself) are pulled from the lang-php bucket, aka normal php buildpack. As I already had that on my TODO list, I just immediately did that :-) … so here’s the new heroku-v8js Github repository that has all the build formulas....

After fixing V8Js’ behaviour of not retaining the object identity of passed back V8Object instances (i.e. always re-wrapping them, instead of re-using the already existing object) I tried how V8Js handles fluent setters (those that return $this at the end). Unfortunately they weren’t handled well, that is V8Js always wrapped the same object again and again (in both directions). Functionality-wise that doesn’t make a big difference since the underlying object is the same, hence further setters can still be called....

V8 has support for ES6 Promises and they make a clean JS-side API. So why not create promises from PHP, (later on) being resolved by PHP? V8Js doesn’t allow direct creation of JS objects from PHP-code, a little JS-side helper needs to be used. One possibility is this: class V8PromiseFactory { private $v8; public function __construct(V8Js $v8) { $this->v8 = $v8; } public function __invoke($executor) { $trampoline = $this->v8->executeString( '(function(executor) { return new Promise(executor); })'); return $trampoline($executor); } } … it can be used to construct an API method that returns a Promise like this:...

Playing around with V8’s custom startup snapshots I noticed some funny behaviour regarding Math.random. It is clear that if you call Math.random() within the custom startup code the generated random numbers are baked into the snapshot and then not so random anymore. If you call Math.random() at runtime, without custom startup code, it just behaves as expected: it generates random numbers. However if you have custom startup code, calling Math.random() early on startup, it correctly generates random numbers during startup but it breaks runtime random number generation causing weird error messages like...

Recently @virgofx filed an issue on V8Js whether (startup) performance of V8Js could be increased. He wants to do server-side React rendering and noticed that V8 itself needs roughly 50ms to initialize and then further 60ms to process React & ReactServer javascript code. Way too much for server side rendering (on more or less every request). Up to V8 4.4 you simply could compile it with snapshots and V8Js made use of them....

For some weeks now I had the idea that V8Js must be running on PHP7 the day it is officially published. So when I started out porting soon after they published he first release candidate (aka 7.0.0RC1) I felt some pressure, especially after noticing that it really will be a lot of work to do. The more glad I am to announce today, that V8Js finally compiles fine and passes the whole test suite from the master branch (apart from tiny modifications that became necessary due to PHP 5....

Today as well as last Thursday I uploaded two more V8Js releases to PECL, both fixing issues around v8::FunctionTemplate usage that bit me at work. Those v8::FunctionTemplate objects are used to construct constructor functions (and thus object templates) in V8. The problem with them? They are not object to garbage collection. So if we export a object with a method attached to it from PHP to JS, V8Js at first exports the object (and caches the v8::FunctionTemplate used to construct it; re-using it on subsequent export of the same class)....

Today I noticed, that invocations of V8Function objects have a really poor call performance. A simple example might be: $v8 = new V8Js(); $func = $v8->executeString('(function() { print("Hello\\n"); });'); for($i = 0; $i < 1000; $i ++) { $func(); } … on my laptop this takes 2.466 seconds (with latest V8Js 0.2.1); older versions like V8Js 0.1.5 even take 80 seconds. That felt strange, since V8Js performance generally is pretty good and the slightly changed version...

After waiting for a really long time (half a year) I finally have an approved php.net + PECL account granted with lead-rights on V8Js :-) … therefore I finally published V8Js version 0.2.0, succeeding 0.1.5 which was published 1.5 years ago. Changes include adapt to latest v8 API (v8 versions from 3.24.6 up to latest 4.3 branch supported now) v8 debugging support apply time & memory limits to V8Function calls...

Today the last pull request in a series of contributions to the V8Js PHP extension has been merged. Good time to loose some words on the project and why I like it, so here we go :-) V8Js is a PHP extension that integrates Google’s V8 JavaScript engine into PHP. This is the extension allows you to execute JavaScript code securely sandboxed from PHP. Besides it allows for simple exchange of data from PHP to JavaScript and back....