Original commit message:
```
Stop profiler on isolate teardown if still running
If the profiler is started via the API and not stopped, V8 will
intermittently crash during isolate teardown.
The fix is to run the DeleteAllProfiles function in Isolate::Deinit()
if cpu_profiler_ still exists.
https://groups.google.com/forum/#!topic/v8-dev/WsIlpbaD4mo
TEST= Run in debug mode, if you start a profile and don't stop it,
this assert should fail:
Fatal error in ../src/profiler/cpu-profiler.cc, line 414
Check failed: !is_profiling_.
Review URL: https://codereview.chromium.org/1526253005
Cr-Commit-Position: refs/heads/master@{#32953}
```
PR-URL: https://github.com/nodejs/node/pull/5024
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Original commit message:
[heap] fix crash during the scavenge of ArrayBuffer
Scavenger should not attempt to visit ArrayBuffer's storage, it is a
user-supplied pointer that may have any alignment. Visiting it, may
result in a crash.
BUG=
R=jochen
Review URL: https://codereview.chromium.org/1406133003
Cr-Commit-Position: refs/heads/master@{#31611}
PR-URL: https://github.com/nodejs/node/pull/4259
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
Ref: #3036
Ref: https://github.com/nodejs/node/pull/3481
PR-URL: https://github.com/nodejs/node/pull/4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
Use baseline code to compute message locations.
This switches Isolate::ComputeLocation to use baseline code when
computing message locations. This unifies locations between optimized
and non-optimized code by always going through the FrameSummary for
location computation.
R=bmeurer@chromium.org
TEST=message/regress/regress-4266
BUG=v8:4266
LOG=n
Review URL: https://codereview.chromium.org/1331603002
Cr-Commit-Position: refs/heads/master@{#30635}
Fixes: https://github.com/nodejs/node/issues/3934
PR-URL: https://github.com/nodejs/node/pull/3937
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This is a reland of https://github.com/nodejs/node/pull/3165. The patch abates
the truncation of script filenames in the perf-event output produced by V8.
V8 commits:
Original: 03ef3cd004
Reland: 010897c16a
Original commit message:
improve perf_basic_prof filename reporting
The buffer used for appending filenames to the string printed to the
perf_basic_prof log was unnecessarily too small. Bump it up to be at least
kUtf8BufferSize.
Truncation of filenames makes it really hard to work with profiles gathered on
Node.js. Because of the way Node.js works, you can have node module dependencies
in deeply nested directories. The last thing you want when investigating a
performance problem is to have script names be truncated.
This patch is a stop-gap. Ideally, I want no truncation of the filename at all
and use a dynamically growing buffer. That would be a larger change, and I
wanted to have a quick fix available that can be back-ported to Node.js LTS
release.
R=yangguo@chromium.org,yurys@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1388543002
PR-URL: https://github.com/nodejs/node/pull/3520
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
[heap] fix crash during the scavenge of ArrayBuffer
Scavenger should not attempt to visit ArrayBuffer's storage, it is a
user-supplied pointer that may have any alignment. Visiting it, may
result in a crash.
BUG=
R=jochen
Review URL: https://codereview.chromium.org/1406133003
Cr-Commit-Position: refs/heads/master@{#31611}
PR-URL: https://github.com/nodejs/node/pull/3549
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This a backport of the following commits from the v8's upstream:
* 1a8c38c50513f9af07ada479629a653e1cf36ff3
* 206f12abee3f1e7eda8fc6521d48f3c319460ee1
* 9e3676da9ab1aaf7de3e8582cb3fdefcc3dbaf33
Original commit message:
heap: make array buffer maps disjoint
Remove intersection from the `std::map`s representing current live
ArrayBuffers. While being simpler to understand, it poses
significant performance issue for the active ArrayBuffer users (like
node.js).
Store buffers separately, and process them together during
mark-sweep phase.
The results of benchmarks are:
$ ./node-slow bench && ./node-fast bench
4997.4 ns/op
4685.7 ns/op
NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js
with vanilla v8.
Ref: https://github.com/nodejs/node/pull/2732
PR-URL: https://github.com/nodejs/node/pull/3351
Reviewed-By: indutny - Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
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=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
PR: #3036
PR-URL: https://github.com/nodejs/node/pull/3036
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
Reduces likelihood of the filename being truncated in /tmp/perf-*.map when
profiling with --perf_basic_prof.
PR-URL: https://github.com/nodejs/node/pull/3165
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
03ef3cd004
Original commit message:
improve perf_basic_prof filename reporting
The buffer used for appending filenames to the string printed to the
perf_basic_prof log was unnecessarily too small. Bump it up to be at least
kUtf8BufferSize.
Truncation of filenames makes it really hard to work with profiles gathered on
Node.js. Because of the way Node.js works, you can have node module dependencies
in deeply nested directories. The last thing you want when investigating a
performance problem is to have script names be truncated.
This patch is a stop-gap. Ideally, I want no truncation of the filename at all
and use a dynamically growing buffer. That would be a larger change, and I
wanted to have a quick fix available that can be back-ported to Node.js LTS
release.
R=yangguo@chromium.org,yurys@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1388543002
Cr-Commit-Position: refs/heads/master@{#31092}
Backport 357e6b99ee3927cc075dd8d27c99b89d858f9dd5 from V8's upstream.
Original commit message:
Add ScopeInfo constants to post-mortem metadata
mdb_v8, a post-mortem debugging tool for Node.js, allows users to
inspect ScopeInfo structures in order to get more information about
closures.
Currently, it hardcodes the metadata it uses to find this information.
This change allows it to get this metadata from the node binary itself,
and thus to adapt to future changes made to the layout of the ScopeInfo
data structure.
BUG=
R=bmeurer@chromium.org
PR: #2974
PR-URL: https://github.com/nodejs/node/pull/2974
Reviewed-By: Rod Vagg <r@va.gg>
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
Original commit message:
[es6] Bound function name
Instead of updating the SharedFuntionInfo set the name property on
the function directly.
BUG=v8:4278
LOG=N
R=verwaest@chromium.org, littledan@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1227523003
Cr-Commit-Position: refs/heads/master@{#29558}
Fixes: https://github.com/nodejs/node/issues/2754
PR-URL: https://github.com/nodejs/node/pull/2916
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
TypedArray accessor detection: consider entire prototype chain
When looking up a special accessor for known TypedArray fields
("length", "byteLength", "byteOffset"), consider the entire
prototype chain, not only the direct prototype.
This allows subclasses of TypedArrays to benefit from fast
specialized accesses.
Review URL: https://codereview.chromium.org/1313493005
Cr-Commit-Position: refs/heads/master@{#30678}
Benchmark results:
buffers/buffer-iterate.js size=16386 type=slow method=for n=1000:
./node: 71607 node: 8702.3 ............ 722.85%
Improvement depends on the code, but generally brings us back to the
performance that we had before the v8 update (if not making it
faster).
Fixes: https://github.com/nodejs/node/issues/2463
PR-URL: https://github.com/nodejs/node/pull/2801
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This a backport of the following commits from the v8's upstream:
* 1a8c38c50513f9af07ada479629a653e1cf36ff3
* 206f12abee3f1e7eda8fc6521d48f3c319460ee1
* 9e3676da9ab1aaf7de3e8582cb3fdefcc3dbaf33
Original commit message:
heap: make array buffer maps disjoint
Remove intersection from the `std::map`s representing current live
ArrayBuffers. While being simpler to understand, it poses
significant performance issue for the active ArrayBuffer users (like
node.js).
Store buffers separately, and process them together during
mark-sweep phase.
The results of benchmarks are:
$ ./node-slow bench && ./node-fast bench
4997.4 ns/op
4685.7 ns/op
NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js
with vanilla v8.
PR-URL: https://github.com/nodejs/node/pull/2732
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Roman Reiss <me@silverwind.io>
Note: chunk in test-heap.cc:1989 discarded as related code missing
from current version in node.
Original commit message:
Use static_cast<> for NULL (clang 3.7)
The following errors come up when compiling v8
with clang 3.7 on FreeBSD/amd64:
src/runtime/runtime-i18n.cc:629:37: error: reinterpret_cast from
'nullptr_t' to 'v8::internal::Smi *' is not allowed
local_object->SetInternalField(1, reinterpret_cast<Smi*>(NULL));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test/cctest/test-heap.cc:131:20: error: reinterpret_cast from
'nullptr_t' to 'v8::internal::Object *' is not allowed
Handle<Object> n(reinterpret_cast<Object*>(NULL), isolate);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test/cctest/test-heap.cc:1989:18: error: reinterpret_cast from
'nullptr_t' to 'Address' (aka 'unsigned char *') is not
allowed
Address base = reinterpret_cast<Address>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+add myself to the AUTHORS file.
BUG=
Review URL: https://codereview.chromium.org/1277353002
Cr-Commit-Position: refs/heads/master@{#30103}
PR-URL: https://github.com/nodejs/node/pull/2636
Reviewed-By: thefourtheye - Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Upgrade the bundled V8 and update code in src/ and lib/ to the new API.
Notable backwards incompatible changes are the removal of the smalloc
module and dropped support for CESU-8 decoding. CESU-8 support can be
brought back if necessary by doing UTF-8 decoding ourselves.
This commit includes https://codereview.chromium.org/1192973004 to fix
a build error on python 2.6 systems. The original commit log follows:
Use optparse in js2c.py for python compatibility
Without this change, V8 won't build on RHEL/CentOS 6 because the
distro python is too old to know about the argparse module.
PR-URL: https://github.com/nodejs/io.js/pull/2022
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
* @indutny's SealHandleScope patch (484bebc38319fc7c622478037922ad73b2edcbf9)
has been cherry picked onto the top of V8 to make it compile.
* There's some test breakage in contextify.
* This was merged at the request of the TC.
PR-URL: https://github.com/iojs/io.js/pull/1632
Original commit log follows:
Meaningful name for builtins in JitCodeEvent API.
Report builtins by name (e.g. "Builtin:ArgumentsAdaptorTrampoline")
instead of labeling everything "Builtin:A builtin from the snapshot"
Review URL: https://codereview.chromium.org/1216833002
PR-URL: https://github.com/nodejs/io.js/pull/2075
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This commit applies a secondary change in order to make `make test`
pass cleanly, specifically re-disabling post-mortem debugging in
common.gypi.
PR-URL: https://github.com/iojs/io.js/pull/1506
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This includes the out-of-tree patch (but fixed in upstream HEAD) from
commit 41c00a2 ("deps: enable v8 postmortem debugging again".)
PR-URL: https://github.com/iojs/io.js/pull/1399
Reviewed-By: Fedor Indutny <fedor@indutny.com>
This commit applies some secondary changes in order to make `make test`
pass cleanly:
* disable broken postmortem debugging in common.gypi
* drop obsolete strict mode test in parallel/test-repl
* drop obsolete test parallel/test-v8-features
PR-URL: https://github.com/iojs/io.js/pull/1232
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Original commit message:
api: introduce SealHandleScope
When debugging Handle leaks in io.js we found it very convenient to be
able to Seal some specific (root in our case) scope to prevent Handle
allocations in it, and easily find leakage.
R=yangguo
BUG=
Review URL: https://codereview.chromium.org/1079713002
Cr-Commit-Position: refs/heads/master@{#27766}
Should help us identify and fix Handle leaks in core and user-space code.
NOTE: Works only in Debug build now, but is still better than nothing.
PR-URL: https://github.com/iojs/io.js/pull/1395
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Michael Dawson
Gibson Fahnestock
Ali Ijaz Sheikh
Fedor Indutny
Julien Gilli
Ben Noordhuis
Michaël Zasso
saper
Rod Vagg
Chris Dickinson