Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade V8 to 4.7 into the new vee-eight-4.7 branch #3481

Closed
wants to merge 3 commits into from

Conversation

ofrobots
Copy link
Contributor

This is for vee-eight-4.7. Do not land on master.

This brings in V8 4.7.80.915, along with a back-port of v8/v8@1ee712a which upstream is unable to back-port to 4.7.

@indutny I believe that 1fdec65 and 972a0c8 no longer need to be floated as on master. The V8 4.7 import picks up your array_buffer_tracker changes. Please confirm.

R=@indutny, @nodejs/v8

@ofrobots ofrobots added the v8 engine Issues and PRs related to the V8 dependency. label Oct 22, 2015
@targos
Copy link
Member

targos commented Oct 22, 2015

you are targeting master

@ofrobots
Copy link
Contributor Author

@targos Yeah, I didn't set the target branch at the time of creating the pull request, now it can't be edited unless I close the PR and create a new one 😢. The intent is to push to vee-eight-4.7 and not master. I'll edit the description of the PR to make it clear.

@ofrobots
Copy link
Contributor Author

@targos
Copy link
Member

targos commented Oct 22, 2015

Tests on windows-fanned and arm-fanned couldn't start because of a git timeout: https://ci.nodejs.org/job/node-test-binary-windows/59/console
/cc @nodejs/build

@rvagg
Copy link
Member

rvagg commented Oct 22, 2015

@joaocgreis not sure why we're getting a timeout on those machines but for the original armv6 jobs I had to tweak the jenkins git timeout parameter to make it consistently happier. There's an advanced git option in jenkins job setup that lets you set this, maybe it should be done for the fanned jobs?

@joaocgreis
Copy link
Member

@rvagg increased the timeouts to 30, no harm in that. Note that this failure happened on the master, before the jobs connect to the machines. There are frequent problems connecting to the windows machines, but that's a different thing.

@ofrobots
Copy link
Contributor Author

Updated to V8 4.7.80.15, rebased to latest master, removed the *.orig files from the cherry-pick (sorry), and launched a new CI: https://ci.nodejs.org/job/node-test-pull-request/566/.

@evanlucas
Copy link
Contributor

Looks like one of the freebsd boxes has a hung process.

https://ci.nodejs.org/job/node-test-commit-freebsd/82/nodes=freebsd101-32/

/cc @nodejs/build

@ofrobots
Copy link
Contributor Author

@jbergstroem
Copy link
Member

(fyi i killed all trailing processes yesterday)

@targos
Copy link
Member

targos commented Oct 24, 2015

LGTM

@ofrobots ofrobots force-pushed the vee-eight-4.7 branch 2 times, most recently from fc5d47d to b33ee46 Compare October 25, 2015 15:40
ofrobots and others added 3 commits October 25, 2015 08:46
Pick up the latest branch head for V8 4.7:
v8/v8@b9b1048

Full change history for the 4.7 branch:
https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/4.7

V8 blog post about what is new on V8 4.7:
http://v8project.blogspot.de/2015/10/v8-release-47.html

PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
Array#includes is now available.

PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{nodejs#31111}

Ref: nodejs#3036
PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
@ofrobots
Copy link
Contributor Author

Landed on vee-eight-4.7 in 3d2f2f0 after a rebase (and a new CI https://ci.nodejs.org/job/node-test-pull-request/604/).

@jasnell
Copy link
Member

jasnell commented Oct 26, 2015

Can this be closed then @ofrobots ?

@ofrobots
Copy link
Contributor Author

Closing the issue. Ping @indutny: please open a new issue if this doesn't completely contain your array_buffer_tracker changes upstream.

@ofrobots ofrobots closed this Oct 26, 2015
@ofrobots ofrobots deleted the vee-eight-4.7 branch November 5, 2015 19:23
@ofrobots ofrobots restored the vee-eight-4.7 branch November 5, 2015 19:23
ofrobots added a commit to ofrobots/node that referenced this pull request Nov 12, 2015
Array#includes is now available.

PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
ofrobots pushed a commit to ofrobots/node that referenced this pull request Nov 12, 2015
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{nodejs#31111}

Ref: nodejs#3036
PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
ofrobots added a commit that referenced this pull request Nov 13, 2015
Array#includes is now available.

PR-URL: #3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
misterdjules pushed a commit that referenced this pull request Nov 13, 2015
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{#31111}

Ref: #3036
PR-URL: #3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
ofrobots added a commit to ofrobots/node that referenced this pull request Dec 1, 2015
Array#includes is now available.

PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
ofrobots pushed a commit to ofrobots/node that referenced this pull request Dec 1, 2015
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{nodejs#31111}

Ref: nodejs#3036
PR-URL: nodejs#3481
Reviewed-By: targos - Michaël Zasso <[email protected]>
ofrobots added a commit to ofrobots/node that referenced this pull request Dec 4, 2015
Array#includes is now available.

Ref: nodejs#3481
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
ofrobots pushed a commit to ofrobots/node that referenced this pull request Dec 4, 2015
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{nodejs#31111}

Ref: nodejs#3036
Ref: nodejs#3481
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
ofrobots added a commit that referenced this pull request Dec 4, 2015
Array#includes is now available.

Ref: #3481
PR-URL: #4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
misterdjules pushed a commit that referenced this pull request Dec 4, 2015
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{#31111}

Ref: #3036
Ref: #3481
PR-URL: #4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
scovetta pushed a commit to scovetta/node that referenced this pull request Apr 2, 2016
Array#includes is now available.

Ref: nodejs#3481
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
scovetta pushed a commit to scovetta/node that referenced this pull request Apr 2, 2016
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.

Original commit message:

  Add SetAbortOnUncaughtExceptionCallback API

  The --abort-on-uncaught-exception command line switch makes
  Isolate::Throw abort if the error being thrown cannot be caught by a
  try/catch block.

  Embedders may want to use other mechanisms than try/catch blocks to
  handle uncaught exceptions. For instance, Node.js has "domain" objects
  that have error handlers that can handle uncaught exception like
  following:

  var d = domain.create();

  d.on('error', function onError(err) {
    console.log('Handling error');
  });

  d.run(function() {
    throw new Error("boom");
  });

  These error handlers are called by isolates' message listeners.

  If --abort-on-uncaught-exception is *not* used, the isolate's
  message listener will be called, which will in turn call the domain's
  error handler. The process will output 'Handling error' and will exit
  successfully (not due to an uncaught exception). This is the behavior
  that Node.js users expect.

  However, if --abort-on-uncaught-exception is used and when throwing an
  error within a domain that has an error handler, the process will abort
  and the domain's error handler will not be called. This is not the
  behavior that Node.js users expect.

  Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
  determine when it's not appropriate to abort and instead handle the
  exception via the isolate's message listener.

  In the example above, Node.js would set a custom callback with
  SetAbortOnUncaughtExceptionCallback that would be implemented as
  following (the sample code has been simplified to remove what's not
  relevant to this change):

  bool ShouldAbortOnUncaughtException(Isolate* isolate) {
    return !IsDomainActive();
  }

  Now when --abort-on-uncaught-exception is used, Isolate::Throw would
  call that callback and determine that it should not abort if a domain
  with an error handler is active. Instead, the isolate's message listener
  would be called and the error would be handled by the domain's error
  handler.

  I believe this can also be useful for other embedders.

  BUG=

  [email protected]

  Review URL: https://codereview.chromium.org/1375933003

  Cr-Commit-Position: refs/heads/master@{nodejs#31111}

Ref: nodejs#3036
Ref: nodejs#3481
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Reviewed-By: targos - Michaël Zasso <[email protected]>
Reviewed-By: rvagg - Rod Vagg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants