libv8 is quite a few versions behind stable

These days node is running:

node --version
v6.0.0
node -e "console.log(process.versions.v8)"
5.0.71.35

libv8 gem is at the somewhat old 4.5.95.5, corresponding more or less with Chrome 45 which was released Sep 1 2015

There are a huge amount of performance and security fixes in the engine since. Why is libv8 on such an old version? API changes do not seem too severe https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7fKaPDfotU6huOa1alds/edit

Hey, it's due to incompatibility between the current version of therubyracer and the API of the newer (than 3.16.xx) versions of V8.

See this PR for more information on the progress of the rewrite: rubyjs/therubyracer#348

Here are my notes on possible ways to work around the performance issues with asset generation: #150 (comment)

If you think that there's need to bump the v8 version before TRR's rewrite is somewhat complete, I might find some time to do it.

@cowboyd

@cowboyd do we need the giant refactor to support latest libv8 or can something smaller and more incremental be done now to support current v8 with the larger refactor to follow?

@ignisf

@ignisf I definitely think a bump is needed prior to rewrite, a year and a half in v8 world is enormous amount of change. The security flaws alone are justification enough, I was measuring node to be 20% or so faster on a babel transpile test I was running today, all time was in eval.

@SamSaffron

@SamSaffron There were pretty enormous breaking changes between versions 3 -> 4 that meant almost a complete rewrite of the C layer. There were also just fundamental flaws with it that needed to be addressed. I'm set to begin work on this again on the 1st of June, and I expect to be done by July.

I know that's not the best timeline, but it's the best I can do with the time I have available.

The 5.0 branch now contains IMO release-ready code.

@ignisf

Thinking about this, I think a "mini" embedded v8 would probably be best here. One say that only supports "eval" and attaching blocks, with significantly reduced interoperability vs the full suite of what ruby racer offers.

It has a few advantages (I think)

libv8 will have more than one consumer
will be significantly easier to keep up to date with v8 changes
good enough for majority of v8 embedding needs (uglify and Discourse could get by with eval and block attachments)

Example API

require 'mini-racer'

ctx = Context.new(timeout: 100) 
ctx.eval_file(filename)
ctx.eval('a= function(){return 1+1;}; a()') # => 2
ctx.attach('adder') do |a,b|
   a+b
end
ctx.eval('ruby.adder(1,2)') # => 2

By severely cutting down on supported features a huge amount of surface area can be shaved off, GC and weak refs become less of a concern.

I worry that there is a gigantic effort required to get therubyracer with all its features to where you need it for 1.0 and July can easily slip to August and so on.

In the meantime almost every Rails project out there has a dependency on a version of v8 that was released 2 and a half years ago. It would be nice to have a path forward that is more immune to v8 making severe breaking changes.

@ignisf perhaps do a release of 5.0 so there is something to link against ?

@ignisf

@ignisf ok except for cross runtime exceptions I have most of the stuff working

https://github.com/SamSaffron/mini_racer

Looking forward to the release of libv8

This looks awesome Sam! What about calling it speedracer :)

@cowboyd

@cowboyd honored :) but I think mini_racer is a better name, there is nothing technically stopping us from applying the same perf improvements to therubyracer, in fact now that you have a ref implementation is should be much easier.

GVL release should be fairly straight forward
Doing more from c extension is also doable

I think the key here is the "mini" part of racer, its not the full suite that you get with therubyracer, though, in most use cases you can get by with "mini" cause you can call js from ruby and call ruby from js freely converting primitive types.

The idea behind "mini" is that it is generally enough for the vast majority of projects (most of which just need eval, they don't even need to call ruby from js)

By having a "smaller" gem with less code it is way easier to keep up to date with all the v8 changes and test exhaustively for leaks and stuff

v5.0.71.48.1beta2 up for testing

@ignisf

@ignisf @cowboyd ❤️

gem install mini-racer --pre

Also got this working with travis ... which was not trivial ... needed to also hack up extconf.rb

https://github.com/discourse/mini_racer/blob/master/.travis.yml
https://github.com/discourse/mini_racer/blob/master/ext/mini_racer_extension/extconf.rb

The c++11 dependency in v8 means that gcc4.8 is a minimal dependency... I am considering shipping native gems for mini_racer due to this ...

Travis uses Ubuntu 12.04 by default and that's a pretty ancient platform. I added this to the travis config here to make use of their 14.04 beta which comes with gcc 4.8 by default.

Navigation Menu

Repository navigation

libv8 is quite a few versions behind stable #213

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

libv8 is quite a few versions behind stable #213

Description

Activity

ignisf commented on May 3, 2016

ignisf commented on May 3, 2016

ignisf commented on May 3, 2016

SamSaffron commented on May 3, 2016

SamSaffron commented on May 3, 2016

cowboyd commented on May 3, 2016

cowboyd commented on May 3, 2016

ignisf commented on May 3, 2016

SamSaffron commented on May 4, 2016

SamSaffron commented on May 10, 2016

cowboyd commented on May 10, 2016

SamSaffron commented on May 11, 2016

ignisf commented on May 13, 2016

SamSaffron commented on May 14, 2016

ignisf commented on May 14, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions