Repository navigation
Time to play with V8 4.6 #2688
Description
Activity
They broke it again! 😢
OK it's all working on my side, here is a first CI: https://ci.nodejs.org/job/node-test-commit/501/
I did not apply any floating patch yet, something may be missing.@McFarts Here's the V8 team's blog post on 4.6: http://v8project.blogspot.de/2015/08/v8-release-46.html
There are no plans that I am aware of to add shared-memory multi-threading to V8 as JavaScript is single threaded as per the language spec. Perhaps your multi-core use-cases can be addressed by the cluster module, or perhaps by workers (#2133) if/when they end up landing in Node.
When do you think they will enable memory sharing across cores? I need my global variables and data to be... you know.. really global :P If you know what I mean
Knowing your aforementioned use case (game server?) I think you should focus on other optimizations. You can't multi-thread that in JavaScript.
@McFarts Could you please ask this on stack-overflow instead? This really isn't the place for the questions you are asking.
NAN 2.0.8 test suite passes.
This ready for a CI run?
... the
.gitignoretrolled me again: https://github.com/nodejs/node/blob/master/.gitignore#L26OK now it's compiling: https://ci.nodejs.org/job/node-test-commit/675/
15 remaining items
@bnoordhuis this is a staging branch, right? I suppose someone will add them when merging to real branch
IMO, it would be better to do reviews on
vee-eight-*branches too. This improves collaboration and makes it much faster to land onmasterwhen the the merge time comes.Guess we may put comments on commits.
I agree that it would be better to have a proper review process for
vee-eight-*branches. There are a few situations that we need to decide how to deal with:Initiate the branch
I suggest to cut it from
masterafter the previous one has been merged and start with a PR to upgrade V8 to the next version.Keep the branch up to date with
masterDo we merge
masterinto it or do we regularly rebase onmaster? I am for the second option but in this case how do we review a conflicting rebase ?Keep V8 up to date in the branch
The beta branch of V8 usually has updates more often than the stable one. Do we make a PR for each one of them ?
Do we merge master into it or do we regularly rebase on master ? I am for the second option but in this case how do we review a conflicting rebase ?
I'd vote for rebase as well. See also previous discussion for the 4.5 branch. If there is a commit added to resolve a conflict during rebase, that gets reviewed as well.
The beta branch of V8 usually has updates more often than the stable one. Do we make a PR for each one of them ?
I don't think we have to have a PR for each one of them. I don't think the goal is to review V8 changes but rather to review us picking up those changes at whatever frequency makes sense for us.
Rebased on master, updated V8 to 4.6.85.23 and cherry-picked all backports.
CI: https://ci.nodejs.org/job/node-test-commit/725/794 - test-util-inspect.js not ok 794 test-util-inspect.js # # undefined:1 # [Debug, ObjectIsPromise] # ^ # ReferenceError: ObjectIsPromise is not defined # at <anonymous>:1:9@bnoordhuis It seems that
ObjectIsPromiseisn't exposed anymore in debug context :(Chrome 46 is out so V8 4.6 is now stable.
V8 4.6 is now on master.
Now that 4.5 is on master, we can start working on the
vee-eight-4.6integration branch.I upgraded V8 to 4.6.85.12 (https://github.com/nodejs/node/tree/vee-eight-4.6). Sadly I cannot make it to compile. Here is the error I get:
I am able to compile d8 without any issue on the same version.
/cc @nodejs/v8