- 29 Oct, 2019 1 commit
-
-
Clemens Backes authored
The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned true for compiled frames, but not for interpreted ones. Thus, for interpreted frames we would run into the code for JS frames, which assumes that a {JSFunction} is available. This CL fixes this issue by renaming {IsWasmFrame} to {IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which returns true for both compiled and interpreted frames. R=mstarzinger@chromium.org Bug: chromium:1018227 Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64607}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 25 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
{FrameArray} needs a way to keep {WasmCode} alive from a JS container. This CL instruces {GlobalWasmCodeRef}, which is the equivalent to a global handle: It increments the {WasmCode} reference counter on construction and decrements it on destruction. The {GlobalWasmCodeRef} is held in a {Managed} from JS. R=titzer@chromium.org Bug: v8:8217 Change-Id: I5604a666840c27078db63c8618412ca412525be1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533862 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60441}
-
- 08 Feb, 2019 1 commit
-
-
Matheus Marchini authored
This is a reland of 97628eee. Original change's description: > [error] extend error stack w/ function parameters > > Extend FrameArray to hold weak references to parameters forfunctions in > the call stack. The goal here is to provide more metadata for postmortem > tools (such as llnode), especially in cases of rethrowing (this will be > particularly useful when using postmortem with promises on Node.js). > > Besides postmortem, these changes allow us to print a more detailed > stack trace for errors with parameters types (or even values), which can > be useful since JavaScript functions can receive any number of > parameters of any type, and having a function behave differently > according to the number of parameters received as well as their types is > a common pattern on JS libraries and frameworks. > > R=<U+200B>bmeurer@google.com, yangguo@google.com > > Change-Id: Idf0984d0dbac16041f11d738d4b1c095a8eecd61 > Reviewed-on: https://chromium-review.googlesource.com/c/1289489 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58468} R=bmeurer@google.com, jkummerow@chromium.org, yangguo@google.com Change-Id: I53d90bb862d9c5e9541116b375fa4de70e3e76dd Reviewed-on: https://chromium-review.googlesource.com/c/1405568 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#59458}
-
- 06 Feb, 2019 1 commit
-
-
Simon Zünd authored
This CL adds a method to the factory which converts a stack trace frame represented by a FrameArray plus index, into a StackFrameInfo object. This factory method will later be used to lazily populate stack trace frames when they are retrieved via inspector API. Drive-by: Expose the script id in StackFrameBase. R=jgruber@chromium.org Bug: v8:8742 Change-Id: I79965e466370706593903f3d1a336ac29736f8ac Reviewed-on: https://chromium-review.googlesource.com/c/1454928 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59405}
-
- 09 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The incremental migration required several pairs of functionally equivalent macros. This patch consolidates everything onto the respective new version and drops the obsolete versions. Bug: v8:3770 Change-Id: I4fb05ff223e8250c83a13f46840810b0893f410b Reviewed-on: https://chromium-review.googlesource.com/c/1398223Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58659}
-
- 08 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I9214212454034cf1238cab43dc34d8d9f8ed2d37 Reviewed-on: https://chromium-review.googlesource.com/c/1398222Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58627}
-
- 26 Dec, 2018 2 commits
-
-
Jakob Kummerow authored
This reverts commit 97628eee. Reason for revert: breaks compilation in Lite mode, which does not allow overriding of certain flags. See https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8926078411629093216/+/steps/build/0/steps/compile/0/stdout. Original change's description: > [error] extend error stack w/ function parameters > > Extend FrameArray to hold weak references to parameters for functions in > the call stack. The goal here is to provide more metadata for postmortem > tools (such as llnode), especially in cases of rethrowing (this will be > particularly useful when using postmortem with promises on Node.js). > > Besides postmortem, these changes allow us to print a more detailed > stack trace for errors with parameters types (or even values), which can > be useful since JavaScript functions can receive any number of > parameters of any type, and having a function behave differently > according to the number of parameters received as well as their types is > a common pattern on JS libraries and frameworks. > > R=bmeurer@google.com, yangguo@google.com > > Change-Id: Idf0984d0dbac16041f11d738d4b1c095a8eecd61 > Reviewed-on: https://chromium-review.googlesource.com/c/1289489 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58468} TBR=yangguo@chromium.org,bmeurer@google.com,bmeurer@chromium.org,mat@mmarchini.me Change-Id: Ide0a434c1521ab2bbeca6821397ff63ba7d40fe5 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/1390128Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58469}
-
Matheus Marchini authored
Extend FrameArray to hold weak references to parameters for functions in the call stack. The goal here is to provide more metadata for postmortem tools (such as llnode), especially in cases of rethrowing (this will be particularly useful when using postmortem with promises on Node.js). Besides postmortem, these changes allow us to print a more detailed stack trace for errors with parameters types (or even values), which can be useful since JavaScript functions can receive any number of parameters of any type, and having a function behave differently according to the number of parameters received as well as their types is a common pattern on JS libraries and frameworks. R=bmeurer@google.com, yangguo@google.com Change-Id: Idf0984d0dbac16041f11d738d4b1c095a8eecd61 Reviewed-on: https://chromium-review.googlesource.com/c/1289489 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58468}
-
- 25 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Removing the temporarily duplicated classes FixedArrayPtr and FixedArrayBasePtr. Bug: v8:3770 Change-Id: I056ad74ff69593e9f134ef5c976766812c4d9275 Reviewed-on: https://chromium-review.googlesource.com/c/1345913 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#57807}
-
- 24 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I06f7fb1b2915d1c87162cb464d0ed34d08516e24 Reviewed-on: https://chromium-review.googlesource.com/c/1345909 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57800}
-
- 05 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
and split Smi out of objects.h into smi.h. Bug: v8:3770, v8:5402 Change-Id: I5ff7461495d29c785a76c79aca2616816a29ab1e Reviewed-on: https://chromium-review.googlesource.com/c/1313035Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57252}
-
- 26 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This adds support for Promise.all() to --async-stack-traces (also at zero cost, since we can derive the relevant information from the resolve element closure and context). In case of `Promise.all(a)` the stack trace even tells you which element of `a` is responsible, for example ```js async function fine() {} async function thrower() { await fine(); throw new Error(); } async function test() { await Promise.all([fine(), thrower()]); } ``` will generate the following stack trace ``` Error at thrower (something.js:1:9) at async Promise.all (index 1) at async test (something.js:3:3) ``` so it not only shows the async Promise.all() frames, but even tells the user exactly that the second element of `[fine(), thrower()]` is the relevant one. Bug: v8:7522 Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45 Reviewed-on: https://chromium-review.googlesource.com/c/1299248Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57023}
-
- 04 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This introduces a new flag --async-stack-traces, which enables zero-cost async stack traces. This enriches the non-standard Error.stack property with async stack frames computed from walking up the promise chains and collecting all the await suspension points along the way. In Error.stack these async frames are marked with "async" to make it possible to distinguish them from regular frames, for example: ``` Error: Some error message at bar (<anonymous>) at async foo (<anonymous>) ``` It's zero-cost because no additional information is collected during the execution of the program, but only the information already present in the promise chains is used to reconstruct an approximation of the async stack in case of an exception. But this approximation is limited to suspension points at await's in async functions. This depends on a recent ECMAScript specification change, flagged behind --harmony-await-optimization and implied the --async-stack-traces flag. Without this change there's no way to get from the outer promise of an async function to the rest of the promise chain, since the link is broken by the indirection introduced by await. For async functions the special outer promise, named .promise in the Parser desugaring, is now forcible allocated to stack slot 0 during scope resolution, to make it accessible to the stack frame construction logic. Note that this first prototype doesn't yet work fully support async generators and might have other limitations. Bug: v8:7522 Ref: nodejs/node#11865 Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1256762 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56363}
-
- 10 Aug, 2018 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:7424 Change-Id: Ifa7029872c4d5cfda2f2411534abad6970dda323 Reviewed-on: https://chromium-review.googlesource.com/1156549Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55034}
-
- 13 Jul, 2018 1 commit
-
-
Dan Elphick authored
All auto-generated with some fix-ups including marking the following classes as NeverReadOnlySpaceObject so their GetIsolate/GetHeap methods are safe to use: Code, CodeDataContainer, AbstractCode, DeoptimizationData, CompilationCacheTable, NormalizedMapCache, Script, SharedFunctionInfo TBR=yangguo@chromium.org Bug: v8:7786 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I6cb5dcca88a0bc99b5afe80f553e06a661b5da3c Reviewed-on: https://chromium-review.googlesource.com/1135306 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#54439}
-
- 11 Jul, 2018 1 commit
-
-
Dan Elphick authored
Removes GetHeap/GetIsolate from FixedArray::Shrink and FixedArray::SetAndGrow. Bug: v8:7786 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8db2680f5ef69e901383e0b2cb60198c1b8dd316 Reviewed-on: https://chromium-review.googlesource.com/1131184Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#54373}
-
- 14 Mar, 2018 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:7549 Change-Id: Ie2d9d9b569b46396e78b3a6c39fe7e36b6090608 Reviewed-on: https://chromium-review.googlesource.com/962247Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51923}
-
- 28 Nov, 2017 3 commits
-
-
Mircea Trofin authored
This reverts commit b301203e. Reason for revert: Fixed issues on arm. Original change's description: > Revert "[wasm] JIT using WasmCodeManager" > > This reverts commit d4c8393c. > > Reason for revert: Breaks ARM hardware: > https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268 > > Original change's description: > > [wasm] JIT using WasmCodeManager > > > > This is the first step towards wasm code sharing. This CL moves wasm > > code generation outside the JavaScript GC heap using the previously - > > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native > > flag). > > > > See design document: go/wasm-on-native-heap-stage-1 > > > > This CL doesn't change other wasm architectural invariants. We still > > have per-Isolate wasm code generation, and per-wasm module instance > > code specialization. > > > > Bug:v8:6876 > > > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3 > > Reviewed-on: https://chromium-review.googlesource.com/674086 > > Reviewed-by: Ben Titzer <titzer@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#49689} > > TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:6876 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Reviewed-on: https://chromium-review.googlesource.com/794690 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49691} TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6876 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/794434 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49692}
-
Michael Achenbach authored
This reverts commit d4c8393c. Reason for revert: Breaks ARM hardware: https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268 Original change's description: > [wasm] JIT using WasmCodeManager > > This is the first step towards wasm code sharing. This CL moves wasm > code generation outside the JavaScript GC heap using the previously - > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native > flag). > > See design document: go/wasm-on-native-heap-stage-1 > > This CL doesn't change other wasm architectural invariants. We still > have per-Isolate wasm code generation, and per-wasm module instance > code specialization. > > Bug:v8:6876 > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3 > Reviewed-on: https://chromium-review.googlesource.com/674086 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Reviewed-by: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49689} TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6876 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49691}
-
Mircea Trofin authored
This is the first step towards wasm code sharing. This CL moves wasm code generation outside the JavaScript GC heap using the previously - introduced WasmCodeManager (all this, behind the --wasm-jit-to-native flag). See design document: go/wasm-on-native-heap-stage-1 This CL doesn't change other wasm architectural invariants. We still have per-Isolate wasm code generation, and per-wasm module instance code specialization. Bug:v8:6876 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3 Reviewed-on: https://chromium-review.googlesource.com/674086Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49689}
-
- 29 Jun, 2017 1 commit
-
-
titzer authored
R=marja@chromium.org BUG= Review-Url: https://codereview.chromium.org/2961253002 Cr-Commit-Position: refs/heads/master@{#46321}
-
- 16 Jun, 2017 1 commit
-
-
Michael Starzinger authored
This removes the heuristic from {JSStackFrame::IsConstructor} that tried to infer whether a frame was called as a constructor or not from the receiver value. We are now carrying along the appropriate bit derived from the frame type instead. R=jgruber@chromium.org TEST=message/regress/regress-5727 BUG=v8:5727 Change-Id: I0e2f1d0f95485c84c4ebcd3cbfe0123c6afd2e01 Reviewed-on: https://chromium-review.googlesource.com/500313 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45972}
-
- 12 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
For more static type safety: Avoid passing wasm objects as Object and casting them before use. Use the correct type right away. R=ahaas@chromium.org BUG=v8:6474 Change-Id: Id0c486560115dd1a7bd9b6a12d2fb938e06520ef Reviewed-on: https://chromium-review.googlesource.com/530744Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45838}
-
- 24 Mar, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5402 R=mstarzinger@chromium.org Change-Id: I4220cd1d7907f9c353265aeab38ee53dcf6f56b6 Reviewed-on: https://chromium-review.googlesource.com/459541Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44112}
-