- 12 Jun, 2019 24 commits
-
-
Z Nguyen-Huu authored
Extend same approach for FastJSArray to FastJSArrayForRead in ArrayMap builtin ~6x perf improvement in micro-benchmark JSTests/ObjectFreeze Before: ArrayMap ArrayMap-Numbers(Score): 0.0887 After: ArrayMap ArrayMap-Numbers(Score): 0.531 Bug: v8:6831 Change-Id: I06cba44ca4c9198977c6da522b782b61f9df04fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653732 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62127}
-
Milad Farazmand authored
Port ea420655 Original Commit Message: API calls made via the CallApiCallback builtin, which is used from the ICs and optimized code, are currently misattributed to the wrong counter InvokeFunctionCallback instead of FunctionCallback. In addition we don't use the C trampoline when only runtime call stats are enabled, but the Chrome DevTools profiler is not active, which means that these calls will not be attrituted properly at all, and that had to be worked around using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is active and not inlining calls/property accesses into optimized code depending on the state of RCS). All of this was really brittle and only due to the fact that the central builtin didn't properly check for RCS (in addition to checking for the CDT profiler). With this fix it's now handled in a central place and attributed to the correct category, so user code doesn't need to worry about RCS anymore and can just call straight into the fast-path. core hand-written native code with the API callback logic. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2d200be4544cf62393330bb2891b6ba6f088db68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655343Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62126}
-
Milad Farazmand authored
Original commit: 303ca9ac Change-Id: I276bc68253fe4cedecdd2a77db0e8dbbc998c1a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652504Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62125}
-
Z Nguyen-Huu authored
Bug: v8:6831 Change-Id: I79cd1e25ddca17f0d5026bee737cd3fde0041e85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653733 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Seth Brenith authored
This change adjusts object initialization order for a few classes so that the GC can never see those objects in an invalid, partially- initialized state. AccessorInfo: Just zeros out a few fields upon construction. This is the simplest case. FunctionTemplateInfo: Slightly changes the order in which fields are set, so that the Smi field is set ahead of the call to SetCallHandler, which can GC. Also a pretty simple case. JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec requires that we start with OrdinaryCreateFromConstructor, which has observable side effects (it fetches the prototype from the new.target). So we split JSObject::New in half: the first half does all of the user- visible things and returns a Map, which we can pass to the second half when we're ready to actually allocate the object. JSTypedArray: Extends the pattern from JSListFormat into Torque code: start with a Map and don't allocate the object until we're ready to set all of its properties. Bug: v8:9311 Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Sathya Gunasekaran authored
Make sure to use the callback passed to cleanupSome Bug: v8:8179 Change-Id: Ia5d90b56edf80e05bdaf0dc520b555c29042b64c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655306Reviewed-by:
-
Georg Schmid authored
R=jarin@chromium.org, tebbi@chromium.org Change-Id: Iec887aec4ae0fc477176a7431a1bd0de0775c060 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645325 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62121}
-
Seth Brenith authored
I originally marked AllocationMemento::allocation_site as @noVerifier out of an abundance of caution because AllocationMemento::IsValid checks whether allocation_site is an AllocationSite. However, I can't find any way for allocation_site to not be an AllocationSite. Bug: v8:9311 Change-Id: I8b7ab51978c90d9baff42dace28d176a1cd2921a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653520Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#62120}
-
Mathias Bynens authored
With bytecode flushing and lazy feedback allocation, we need to call %PrepareForOptimization before we call %OptimizeFunctionOnNextCall, ideally after declaring the function. Bug: v8:8801, v8:8394, v8:9183 Change-Id: I3fb257282a30f6526a376a3afdedb44786320d34 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648255 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62119}
-
Jakob Gruber authored
This adds regexp-macro-assembler-arch.h which contains the arch-specific include dispatch. Change-Id: Ibc2be8059d54b57afeed9b7ce244229ce1bd79bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655296 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62118}
-
Benedikt Meurer authored
Make sure that we pop the async function promise from the catch prediction stack when `await`ing inside an async function, and push it back onto the stack when we're resuming execution. This is to ensure that we don't leak memory when there are suspended async functions while navigating away to a new page. Bug: chromium:968603 Change-Id: I004715bc95d426958f1a89ce76c4856da1d4ceee Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655652 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62117}
-
Toon Verwaest authored
Reuse helpers and move generic functions to char-predicates Change-Id: I63bf704bdd8e8cd788e80ad2d42b689527865e00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653118Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62116}
-
Georg Schmid authored
[turbofan] Extend BitcastTaggedToWord(BitcastWordToTaggedSigned(...)) elimination to BitcastTaggedSignedToWord R=tebbi@chromium.org Bug: chromium:973047 Change-Id: I33de86258e04140c6da8099a0d9e4aee3f74abe9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655298 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
-
Benedikt Meurer authored
Previously the object cloning fast-path had a single loop which would initialize the object _and_ at the same time clone MutableHeapNumbers. But since that can trigger GCs, the heap verifier was a bit sad to see double fields holding undefined values. This was flushed out by the CL https://chromium-review.googlesource.com/1655291, which changed the GC timing slightly and thus made the test crash in the verifier. So instead of the one loop, we now have a second loop that takes care of cloning any MutableHeapNumbers. This has the advantage that the first loop can always run without write barriers. Bug: chromium:964748, chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I724a1c1e534243ce9ecde95bf0c07ca26363b515 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655307 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62114}
-
Jakob Gruber authored
bytecodes-irregexp.h -> regexp-bytecodes.h interpreter-irregexp.{cc,h} -> regexp-interpreter.{cc,h} Change-Id: I98ca9d5c3264ad0adbd280b93082aa3e01b45b67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655294 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: -
Sigurd Schneider authored
This is pre-work for a refactoring that changes how heap objects are handled in the assembler: Currently, we put the handle location in the constant pool, and replace these with the actual heap object when we copy the code from the assembler's buffer to the heap. In the future, we will put a small index in the constant pool, which will ultimately enable 32bit constant pool slots for compressed heap objects. This small index will be fixed up when we copy the code to the heap. This CL makes the assembler tests copy the code to the heap, which ensures that the fix-up phase is actually run. Change-Id: I80cd69dc57414a3bd0a27f8d558616aadcae05a2 Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647166 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Mike Stanton authored
As a component of the wider Turbofan logging scheme, it makes sense for JSHeapBroker logging to come through flags specified in the OptimizedCompilationInfo class, which uses --trace-turbo-filter to control which functions are logged. Bug: v8:7790 Change-Id: I3b068d8be78867ab0bd9607dda9eca4123b9d7b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655297Reviewed-by:
-
Leszek Swirski authored
This reverts commit 823795fc. Reason for revert: Breaks mjsunit/es9/regress/regress-904167 on bots (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26342) Original change's description: > [ic] Fix typo in Runtime_CloneObjectIC_Miss. > > https://chromium-review.googlesource.com/1649554 introduced a typo into > Runtime_CloneObjectIC_Miss, where it wouldn't update the IC state UNLESS > the source map is deprecated, which is the wrong way around of course. > > Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 > Change-Id: I7d6e0709e66ce4aaaf4a628d64ab801b84c8993c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655291 > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62106} TBR=bmeurer@chromium.org,verwaest@chromium.org Change-Id: Ie651523c556b220e57ec5e11e37b0a67936bb291 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655299Reviewed-by:
-
Benedikt Meurer authored
API calls made via the CallApiCallback builtin, which is used from the ICs and optimized code, are currently misattributed to the wrong counter InvokeFunctionCallback instead of FunctionCallback. In addition we don't use the C trampoline when only runtime call stats are enabled, but the Chrome DevTools profiler is not active, which means that these calls will not be attrituted properly at all, and that had to be worked around using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is active and not inlining calls/property accesses into optimized code depending on the state of RCS). All of this was really brittle and only due to the fact that the central builtin didn't properly check for RCS (in addition to checking for the CDT profiler). With this fix it's now handled in a central place and attributed to the correct category, so user code doesn't need to worry about RCS anymore and can just call straight into the fast-path. Drive-by-fix: Do the same for AccessorInfo getter calls, which share the core hand-written native code with the API callback logic. Bug: v8:9183 Change-Id: Id0cd99d3dd676635fe3272b67cd76a19a9a9cea4 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1651470 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Nico Weber authored
The C++ standard says that template functions should be parsed immediately, and only type-dependent things should be deferred. cl.exe (MSVC's compiler) instead deferred parsing of all template functions until the end of the translation unit, and unreferenced template functions are not parsed at all. clang-cl emulates cl.exe's behavior. Recently, cl.exe (and clang-cl) grew a /Zc:twoPhase flag that opts in to the standards-conforming behavior, and system headers are now clean enough to build with this flag set. This cleans up v8 to also build with this flag. There was just a single issue: RecyclingZoneAllocator() is unused and contains invalid code: It calls the superclass ctor using `ZoneAllocator(nullptr, nullptr)`, when it should be doing `ZoneAllocator<T>(nullptr, nullptr)`. With /Zc:twoPhase, this is now a parsing error. However, since the RecyclingZoneAllocator() default constructor isn't used anywhere, just delete it. Finally, improve the comment for ZoneAllocator's default constructor to explain why it's needed on Windows. Bug: chromium:969702 Change-Id: I7a516afde67fe090a512d7c7214a3c6932754aca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652503 Auto-Submit: Nico Weber <thakis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Igor Sheludko authored
... in favor of Isolate*. It seems that it's better to be uniform in using Isolate* or isolate root value, so if we decide to pass isolate root value instead of Isolate* it should better be done everywhere and it will be a separate CL anyway. Regarding the "optionality" of the isolate parameter - C++ compilers are smart enough to optimize it away during inlining. Bug: v8:9353 Change-Id: Idf86a792476f49393041ced1c54b8671f5b1794a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653121 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
https://chromium-review.googlesource.com/1649554 introduced a typo into Runtime_CloneObjectIC_Miss, where it wouldn't update the IC state UNLESS the source map is deprecated, which is the wrong way around of course. Bug: chromium:973045, v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I7d6e0709e66ce4aaaf4a628d64ab801b84c8993c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655291 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Frank Tang authored
Add special condiction in ecma262 #sec-runtime-semantics-canonicalize-ch Step 3.g-h. Bug: chromium:971636 Change-Id: Id533beb66749af6e38ee114cf79f995a1156df20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652795Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/aeede42..4b9a126 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ace1f8b..4d6b614 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fd919c8..374a128 TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: Ie258068eb50ca488b2bbc7a247a5e1d22bd8094d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654522Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#62104}
-
- 11 Jun, 2019 16 commits
-
-
Guanzhong Chen authored
Currently, in wasm-function stack traces, v8 displays the decimal offset from the start of the function. However, the WebAssembly WebAPI specification says that it should be a hex offset into the module. This change makes the stack trace display with hex module offsets, as well as fixing all the unit tests that depended on the old behaviour. R=fgm@chromium.org, titzer@chromium.org, yangguo@chromium.org Bug: v8:9172 Change-Id: I73737a319a42dd665521ab8a4b825199ae11c87f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646846Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Guanzhong Chen <gzchen@google.com> Cr-Commit-Position: refs/heads/master@{#62103}
-
Johannes Henkel authored
https://chromium.googlesource.com/v8/v8.git/+/refs/heads/7.6-lkgr/include/v8-inspector.h has the V8_DEPRECATED method. And looks like https://chromium.googlesource.com/v8/v8.git/+/refs/heads/7.7.1 has been cut, so this is no longer needed. Change-Id: I9db414df4900fc24cd6789708464f9d90bfb64f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649344Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
-
Z Nguyen-Huu authored
Bug: v8:6664 Change-Id: Iaef787b3b0c2a24de57b7c3a5c4e75e5a723228e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652061 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Georg Schmid authored
R=tebbi@chromium.org Change-Id: Iab4b0a69028386e79b9abdbcaee7fdb10871042f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653119 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
-
Caitlin Potter authored
It was a good flag, but it's time to say goodbye. Let us take a moment to remember the good times we've had during its short time on earth. It shipped in Chrome 74. BUG=v8:8523 R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Auto-Submit: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#62099}
-
Georg Schmid authored
R=machenbach@chromium.org, tebbi@chromium.org Change-Id: I99a5d5200ef7e0e812a2bf1e22a5f8ff813a1ca6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653117Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#62098}
-
Jose Dapena Paz authored
elements.cc invokes ApplyAttributesToDictionary using NumberDictionary as its template parameter. But the declaration of the template method is in js-object.cc, so nobody can actually compile the version for number dictionary. This is fixed requesting explicit instantiation for NumberDictionary. This was breaking GCC build. Bug: chromium:819294 Change-Id: I685ddc5b97e129d1a534dbdb04025c0932bc5ecd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649565Reviewed-by:
-
Z Nguyen-Huu authored
Extend CodeStubAssembler::TryLookupElement() to handle frozen/sealed elements. Also add some tests. ~2x perf improvement in micro-benchmark ObjectFreeze Before: TaggedTemplate TaggedTemplate-Numbers(Score): 2.43 HasOwnProperty HasOwnProperty-Numbers(Score): 2.94 After: TaggedTemplate TaggedTemplate-Numbers(Score): 4.77 HasOwnProperty HasOwnProperty-Numbers(Score): 4.68 Bug: v8:6831 Change-Id: I6ce057fd812cd6a01e627125a51eefa439710274 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1650633 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Joyee Cheung authored
This helps debugging incorrect usage of the SnapshotCreator API in debug mode. Change-Id: Ibd9db76a5f460cdf7ea6d14e865592ebaf69aeef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648240Reviewed-by:
-
Dan Elphick authored
Changes calls to conversion builtins in Wasm wrappers to use the builtin address directly rather than going via the Code object which results in the trampoline being unnecessarily executed. Bug: v8:9338 Change-Id: I74593dbda3c8bd308be65bc98ce85213a98f78b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648274Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62094}
-
Z Nguyen-Huu authored
Bug: v8:6831 Change-Id: I906dcc363620fda97f00cb02b68c3e393471076d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1651144Reviewed-by:
-
Simon Zünd authored
This CL adds lint errors for unused Torque macros. To prevent lots of noisy warnings, the check is rather narrow. Macros declared as "extern" or marked with "@export" are ignored. Also macros starting with "Convert", "Cast" or "FromConstexpr" are not checked. Drive-by: Removing some unused macros. Bug: v8:7793 Change-Id: Ie0d2e445f8882a9b0ebbda45876b342abf341248 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645312 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Dan Elphick authored
This reverts commit 69fafb5f. Reason for revert: V8 Linux64 GC Stress - custom snapshot https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/26291 Original change's description: > Enable lazy source positions by default > > Also adds a compile time flag which allows the default to be configured > so node can disable it since it hangs the node cpu profiler tests. > > Bug: v8:8510 > Change-Id: Idf4785036dc6242769410091518a67ac9179b718 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1491491 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62089} TBR=rmcilroy@chromium.org,delphick@chromium.org Change-Id: I92a64ddc63e36ec326e6d8ba1a5b68af38e3134b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653112Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62091}
-
Jakob Gruber authored
An error object's 'stack' property is lazily formatted once the property is first read. It is thus possible that lazy formatting happens in a different realm than where the error object was constructed. In this case, we should use the origin-realm's prepareStackTrace function to format the stack trace. This CL implements that behavior by fetching prepareStackTrace from the given error object's context's error function. Bug: v8:7848 Change-Id: Ibc383cf24f2c0dab2fd8bb7bc740f1488d9954a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1113438 Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Dan Elphick authored
Also adds a compile time flag which allows the default to be configured so node can disable it since it hangs the node cpu profiler tests. Bug: v8:8510 Change-Id: Idf4785036dc6242769410091518a67ac9179b718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1491491Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62089}
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: If184e02eef8cda459a3aa02ef8bee5c337177d30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648264Reviewed-by:
-
