-
Notifications
You must be signed in to change notification settings - Fork 71
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
vm: migrate to new v8 api #147
Conversation
Original commit message: [testrunner] delete ancient junit compatible format support Testrunner has ancient support for JUnit compatible XML output. This CL removes this old feature. [email protected],[email protected],[email protected] CC=[email protected] Bug: v8:8728 Change-Id: I7e1beb011dbaec3aa1a27398a5c52abdd778eaf0 Reviewed-on: https://chromium-review.googlesource.com/c/1430065 Reviewed-by: Jakob Gruber <[email protected]> Reviewed-by: Michael Starzinger <[email protected]> Commit-Queue: Tamer Tas <[email protected]> Cr-Commit-Position: refs/heads/master@{#59045} Refs: v8/v8@bd019bd PR-URL: nodejs/node#26685 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
PR-URL: nodejs/node#26685 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
Patch V8 (compiler/js-heap-broker.cc) to remove the use of an optional property, which is a fairly new C++ feature, since that requires a newer XCode version than the minimum requirement in BUILDING.md and thus breaks CI. PR-URL: nodejs/node#29694 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]>
This commit updates V8's postmortem metadata generation script to support V8 7.8. The following metadata has changed: - v8dbg_class_JSDate__value__Object - The postmortem metadata generation script needed to be updated. No action should be required by postmortem tools. - v8dbg_class_JSRegExp__source__Object - The postmortem metadata generation script needed to be updated. No action should be required by postmortem tools. PR-URL: nodejs/node#29694 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]>
This commit updates V8's postmortem metadata generation script. This commit re-exposes the v8dbg_class_UncompiledData__inferred_name__String constant after it moved to Torque. PR-URL: nodejs/node#30020 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
Fixes a compilation issue on some platforms PR-URL: nodejs/node#27375 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
This should be semver-patch since actual invocation is version conditional. PR-URL: nodejs/node#27375 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
There is a bug in the most recent version of VS2015 that affects v8.h and therefore prevents compilation of addons. Refs: https://stackoverflow.com/q/38378693 PR-URL: nodejs/node#30020 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
Co-authored-by: Ujjwal Sharma <[email protected]>
These methods will be removed in V8 8.1, hence we need to stop overriding them.
This reverts commit 5981fb7.
until a16b2c7eef289ddb1007193c1772b7c5f74190cc
until bed702fa07fae0d450b3907b29b4e21d1f41d0b8
This commit updates V8's postmortem metadata generation script to re-expose the v8dbg_class_Map__constructor_or_backpointer__Object constant.
The following metadata has changed in V8: - v8dbg_class_ConsString__first_offset__int - Use v8dbg_class_ConsString__first__String instead. - Refs: v8/v8@b38dfaf - v8dbg_class_ConsString__second_offset__int - Use v8dbg_class_ConsString__second__String instead. - Refs: v8/v8@b38dfaf - v8dbg_class_Map__constructor_or_backpointer__Object - This constant has not changed, but the postmortem metadata generation script required an update. - v8dbg_class_SlicedString__offset_offset__int - Use v8dbg_class_SlicedString__offset__SMI instead. - Refs: v8/v8@b38dfaf - v8dbg_class_ThinString__actual_offset__int - Use v8dbg_class_ThinString__actual__String instead. - Refs: v8/v8@b38dfaf
This commit updates v8abbr.h to use the updated metadata.
until 6bd85fc611dc66d08e6f0708c1b62bf4df3c1216
until 2f205f5a3343b37d3125af88efd925ab300a290e
until 221f4068d34da39726cfd0ac4d746a02e33edde5
until bc0c25b4a0cd29d12bb5acb800b85dbb265580cb
until 15ec4a09d35b31bad7c30db3b639a34e07646317
Fixes the following warning times a gazillion: <command-line>: warning: ISO C++11 requires whitespace after the macro name
It only uses adler32() and only in one place that's arguably not very performance critical so simplify the build by building just adler32.c and nothing else.
Bump minimum version of ICU needed to build node to 65. Refs: v8/v8@74bf96e
Co-authored-by: Ben Noordhuis <[email protected]>
Not sure this is the best way to fix it. The previous api won't work anymore. |
Interesting that the CI / lint-js tests are passing but the Python 3 testing / build (3.8) tests are failing on a JavaScript assertion error. ;-) |
The left failed case beside ws connect (fixed in upstream) both related to |
Yeah, I would assume that something recently changed with respect to some aspects of GC in V8… |
It just demonstrates that static analysis of the JavaScript source (CI / lint-js) alone doesn’t catch errors occurring in running tests. |
Should we report it to https://github.com/v8/node or you can take a look ? |
@gengjiawen I think we should report these as issues on this repository? That’s the way we usually deal with it afaik |
Already have, see #144. (I also put it in PR description). |
38f472a
to
d1a1e20
Compare
Launched via 591b4d2. |
IIRC this PR and 591b4d2 were not the same, but I'll try to double-check tomorrow |
nodejs/node-v8#147 broke the `vm.measureMemory()` API. It only created a `MeasureMemoryDelegate` and without actually calling `v8::Isolate::MeasureMemory()` so the returned promise will never resolve. This was not caught by the tests because the promise resolvers were not wrapped with `common.mustCall()`. This patch migrates the API properly and also introduce the newly added execution option to the API. It also removes support for specifying contexts to measure - instead we'll just return the measurements for all contexts in the detailed mode, which is what the `performance.measureMemory()` prototype in V8 currently does. We can consider implementing our own `v8::MeasureMemoryDelegate` to select the target context in `ShouldMeasure()` in the future, but then we'll also need to implement `MeasurementComplete()` to assemble the result. For now it's probably too early to do that. Since this API is still experimental (and guarded with a warning), such breakage should be acceptable. Refs: nodejs/node-v8#147
nodejs/node-v8#147 broke the `vm.measureMemory()` API. It only created a `MeasureMemoryDelegate` and without actually calling `v8::Isolate::MeasureMemory()` so the returned promise will never resolve. This was not caught by the tests because the promise resolvers were not wrapped with `common.mustCall()`. This patch migrates the API properly and also introduce the newly added execution option to the API. It also removes support for specifying contexts to measure - instead we'll just return the measurements for all contexts in the detailed mode, which is what the `performance.measureMemory()` prototype in V8 currently does. We can consider implementing our own `v8::MeasureMemoryDelegate` to select the target context in `ShouldMeasure()` in the future, but then we'll also need to implement `MeasurementComplete()` to assemble the result. For now it's probably too early to do that. Since this API is still experimental (and guarded with a warning), such breakage should be acceptable. Refs: nodejs/node-v8#147 PR-URL: #32988 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: James M Snell <[email protected]>
nodejs/node-v8#147 broke the `vm.measureMemory()` API. It only created a `MeasureMemoryDelegate` and without actually calling `v8::Isolate::MeasureMemory()` so the returned promise will never resolve. This was not caught by the tests because the promise resolvers were not wrapped with `common.mustCall()`. This patch migrates the API properly and also introduce the newly added execution option to the API. It also removes support for specifying contexts to measure - instead we'll just return the measurements for all contexts in the detailed mode, which is what the `performance.measureMemory()` prototype in V8 currently does. We can consider implementing our own `v8::MeasureMemoryDelegate` to select the target context in `ShouldMeasure()` in the future, but then we'll also need to implement `MeasurementComplete()` to assemble the result. For now it's probably too early to do that. Since this API is still experimental (and guarded with a warning), such breakage should be acceptable. Refs: nodejs/node-v8#147 PR-URL: #32988 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Jiawen Geng <[email protected]> Reviewed-By: James M Snell <[email protected]>
Related: #144.