- 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 2 commits
-
-
Clemens Hammacher authored
* add functionality to wasm-module-builder.js to emit the module name in the name section. * extend WasmModule to store the module name length and offset. * add functionality to module-decoder.cc to decode the module name. * use the module name for printing stack traces. more uses should follow. * extend one message test to contain a module name. R=ahaas@chromium.org Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f Reviewed-on: https://chromium-review.googlesource.com/530366Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45846}
-
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}
-
- 09 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
This CL changes the printed wasm locations to use the spec'ed format (see https://github.com/WebAssembly/design/blob/master/Web.md#developer-facing-display-conventions). Before: <WASM[<id>]+<offset> After: wasm-function[<id>]:<offset> R=ahaas@chromium.org Change-Id: If8018012b518143d6353f5a1f5319764ee46f148 Reviewed-on: https://chromium-review.googlesource.com/529104Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45820}
-
- 06 Jun, 2017 1 commit
-
-
Igor Sheludko authored
Properly propagate the fact that the function has a statically known name from parser to SharedFunctionInfo objects. The empty string that has been set as name before this CL does not help to distinguish cases like: var o1 = { ''(){} }; var o1 = { [foo()](){} }; or var o2 = { get ''(){} }; var o2 = { get [foo()](){} }; This is a preliminary step for using different layouts for closure objects with and without computed names. TBR=bmeurer@chromium.org, marja@chromium.org Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d Reviewed-on: https://chromium-review.googlesource.com/522073 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45744}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 11 May, 2017 1 commit
-
-
jgruber authored
Clearing the pending exception is not enough - if we want to swallow an exception while currently on top of an external handler (e.g. TryCatch), we also need to clear external_caught_exception. BUG=chromium:719380 Review-Url: https://codereview.chromium.org/2870423002 Cr-Commit-Position: refs/heads/master@{#45247}
-
- 14 Apr, 2017 1 commit
-
-
kozyatinskiy authored
- creating JSArray and further setter and getter calls are slower then on fixed array. BUG=v8:6189 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2813773002 Cr-Commit-Position: refs/heads/master@{#44657}
-
- 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}
-
- 17 Mar, 2017 1 commit
-
-
Jochen Eisinger authored
Retrieving information from a message should never execute script or throw exceptions. BUG=v8:5830 R=mmoroz@chromium.org,yangguo@chromium.org Change-Id: Ie8a84ca2cc14eb41ceaf4162d8a5381a20d559bc Reviewed-on: https://chromium-review.googlesource.com/455740 Commit-Queue: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43883}
-
- 16 Mar, 2017 2 commits
-
-
franzih authored
Extract script->type() == TYPE_NORMAL into a function. BUG= Review-Url: https://codereview.chromium.org/2744613006 Cr-Commit-Position: refs/heads/master@{#43868}
-
Clemens Hammacher authored
We were converting an int to a Smi, calling ToString to create a String object, then appending this String to an IncrementalStringBuilder. It's much easier and more efficient to just sprintf to a local buffer and append that instead. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: I9302a07971cfd32350d69b1b8f182d0ba7245b77 Reviewed-on: https://chromium-review.googlesource.com/454018Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#43857}
-
- 14 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
In Isolate::CaptureSimpleStackTrace, we were ignoring interpreter entry frames so far. This CLs changes this to gets the interpreted stack from the wasm interpreter and add the frames to the FrameArray. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: I705909532ff28af412ff809da94522866eaa1c0d Reviewed-on: https://chromium-review.googlesource.com/452378 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43772}
-
- 13 Jan, 2017 1 commit
-
-
mstarzinger authored
This changes the {MessageLocation} structure to no longer contain a concrete {JSFunction} object but rather a {SharedFunctionInfo}. It is much easier by now to determine, and also the concrete closure is never actually being used. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2628973005 Cr-Commit-Position: refs/heads/master@{#42324}
-
- 09 Jan, 2017 1 commit
-
-
cbruni authored
The pattern IsNull(isolate) || IsUndefined(isolate) is used in many places all over the code base. Review-Url: https://codereview.chromium.org/2601503002 Cr-Commit-Position: refs/heads/master@{#42138}
-
- 20 Dec, 2016 1 commit
-
-
clemensh authored
The new object will hold information which is shared by all clones of a WasmCompiledModule, e.g. the decoded asm.js offset table, and in the future also breakpoints. From there, we can set them on each new instantiation of any clone. While already changing lots of the code base, I also renamed all getters from "get_foo" to "foo", to conform to the style guide. R=titzer@chromium.org, yangguo@chromium.org BUG=v8:5732 Review-Url: https://codereview.chromium.org/2591653002 Cr-Commit-Position: refs/heads/master@{#41862}
-
- 19 Dec, 2016 1 commit
-
-
clemensh authored
When executing wasm code for testing, we did not create a WasmInstanceObject and link it to the generated code. This required some special handling at runtime (mainly for stack trace generation). This CL always provides the WasmInstanceObject, such that e.g. function names can be resolved the usual way. The module bytes referenced by the WasmCompiledModule linked with the WasmInstanceObject do not hold a valid wasm module yet. Instead, we just add the bytes we need, and make the objects in WasmModule point to those bytes (currently only used for function names). Those bytes will not be parsed at runtime anyway. R=titzer@chromium.org CC=jgruber@chromium.org BUG=v8:5620 Review-Url: https://codereview.chromium.org/2551053002 Cr-Commit-Position: refs/heads/master@{#41809}
-
- 12 Dec, 2016 3 commits
-
-
bradnelson authored
Generalize Messages to include an error level. Add a parameter to AddMessageHandler to select which error levels to receive, using a mask (default being just errors, i.e. the current behavior). BUG=v8:4203 R=dgozman@chromium.org,machenbach@chromium.org,danno@chromium.org,bmeurer@chromium.org,jochen@chromium.org Review-Url: https://codereview.chromium.org/2526703002 Cr-Commit-Position: refs/heads/master@{#41648}
-
clemensh authored
This CL moves all methods related to scripts and eval origin (HasScript, GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase, because it also applies to WasmFrames. This makes the AppendFileLocation method append the same information to WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames. R=titzer@chromium.org, mstarzinger@chromium.org BUG=v8:4203 Review-Url: https://codereview.chromium.org/2557923005 Cr-Commit-Position: refs/heads/master@{#41642}
-
clemensh authored
The current logic in Isolate::GetLocationFromStackTrace just ignores wasm frames, making the computed location point to the first javascript frame, like this: test.js:17: RuntimeError: divide by zero module.exports.main(); ^ RuntimeError: divide by zero at main (<WASM>[1]+5) at test.js:17:16 This CL not only fixes the location to point to the top-most wasm frame, but also exposes to the embedder that the script of that location is a wasm script, allowing for custom printing of wasm locations. The Shell::ReportException method now checks for this flag, and prints wasm locations like this: <WASM>[0]+5: RuntimeError: divide by zero RuntimeError: divide by zero at main (<WASM>[0]+5) at test/message/wasm-trap.js:15:16 R=titzer@chromium.org, yangguo@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2563673002 Cr-Commit-Position: refs/heads/master@{#41640}
-
- 09 Dec, 2016 2 commits
-
-
yangguo authored
Logging for --perf-prof is not GC safe. Now, we are going to emit source position info for optimized code when we are profiling, logging, or debugging, and under the same condition, pre-compute the line ends array for line number computation. R=tebbi@chromium.org BUG=v8:5730 Review-Url: https://codereview.chromium.org/2562973002 Cr-Commit-Position: refs/heads/master@{#41619}
-
clemensh authored
In the asm.js code translated to wasm, we call imported functions via a WASM_TO_JS stub, which first calls the function and then calls ToNumber on the return value. Exceptions can happen in both calls. We were only ever reporting the location of the function call, whereas asm.js code executed via turbofan reported the location of the type coercion operator ("+" on "+foo()" or "|" on "foo()|0"). This CL implements the same behaviour for asm.js code translated to wasm. The following is changed: - the AsmWasmBuilder records the parent node when descending on a binary operator (also "+foo()" is represented by a binary operation). - it stores not one location per call in the source position side table, but two (one for the call, one for the parent which does the type coercion). - the wasm compiler annotates the source positions "0" and "1" to the two calls in the WASM_TO_JS wrapper (only if the module origin is asm.js). - the StackFrame::State struct now also holds the callee_pc_address, which is set in ComputeCallerState. The WASM frame uses this information to determine whether the callee frame is WASM_TO_JS, and whether that frame is at the ToNumber conversion call. - the same information is also stored in the FrameArray which is used to reconstruct the stack trace later. R=titzer@chromium.org, bradnelson@chromium.org CC=jgruber@chromium.org BUG=v8:4203,v8:5724 Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262 Review-Url: https://codereview.chromium.org/2555243002 Cr-Original-Commit-Position: refs/heads/master@{#41599} Cr-Commit-Position: refs/heads/master@{#41613}
-
- 08 Dec, 2016 2 commits
-
-
clemensh authored
Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ ) Reason for revert: gc-stress failures Original issue's description: > [wasm] Fix location for error in asm.js ToNumber conversion > > In the asm.js code translated to wasm, we call imported functions via a > WASM_TO_JS stub, which first calls the function and then calls ToNumber > on the return value. Exceptions can happen in both calls. > We were only ever reporting the location of the function call, whereas > asm.js code executed via turbofan reported the location of the type > coercion operator ("+" on "+foo()" or "|" on "foo()|0"). > > This CL implements the same behaviour for asm.js code translated to > wasm. The following is changed: > - the AsmWasmBuilder records the parent node when descending on a binary > operator (also "+foo()" is represented by a binary operation). > - it stores not one location per call in the source position side > table, but two (one for the call, one for the parent which does the > type coercion). > - the wasm compiler annotates the source positions "0" and "1" to the > two calls in the WASM_TO_JS wrapper (only if the module origin is > asm.js). > - during stack trace generation (in the StackTraceIterator), when we > move from the WASM_TO_JS frame to the WASM frame, we remember at which > call inside the WASM_TO_JS wrapper we are, and encode this information > in the generated caller state, used for the WASM frame. > - the same information is also stored in the FrameArray which is used > to reconstruct the stack trace later. > > R=titzer@chromium.org, bradnelson@chromium.org > CC=jgruber@chromium.org > BUG=v8:4203,v8:5724 > > Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262 > Cr-Commit-Position: refs/heads/master@{#41599} TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4203,v8:5724 Review-Url: https://codereview.chromium.org/2563613003 Cr-Commit-Position: refs/heads/master@{#41601}
-
clemensh authored
In the asm.js code translated to wasm, we call imported functions via a WASM_TO_JS stub, which first calls the function and then calls ToNumber on the return value. Exceptions can happen in both calls. We were only ever reporting the location of the function call, whereas asm.js code executed via turbofan reported the location of the type coercion operator ("+" on "+foo()" or "|" on "foo()|0"). This CL implements the same behaviour for asm.js code translated to wasm. The following is changed: - the AsmWasmBuilder records the parent node when descending on a binary operator (also "+foo()" is represented by a binary operation). - it stores not one location per call in the source position side table, but two (one for the call, one for the parent which does the type coercion). - the wasm compiler annotates the source positions "0" and "1" to the two calls in the WASM_TO_JS wrapper (only if the module origin is asm.js). - during stack trace generation (in the StackTraceIterator), when we move from the WASM_TO_JS frame to the WASM frame, we remember at which call inside the WASM_TO_JS wrapper we are, and encode this information in the generated caller state, used for the WASM frame. - the same information is also stored in the FrameArray which is used to reconstruct the stack trace later. R=titzer@chromium.org, bradnelson@chromium.org CC=jgruber@chromium.org BUG=v8:4203,v8:5724 Review-Url: https://codereview.chromium.org/2555243002 Cr-Commit-Position: refs/heads/master@{#41599}
-
- 28 Nov, 2016 1 commit
-
-
clemensh authored
Before, the encoded variant was stored in the compiled module, and the decoded one in the debug info (per instance). The decoded table was a FixedArray of ByteArrays. Now, also the decoded table is a flat ByteArray, and it encodes whether it is encoded or decoded. This saves memory and allows to store encoded and decoded variant in the same field. The table is automatically decoded on the first use. This CL also removes some unused and unimplemented methods from WasmDebugInfo (probably merge artifacts). That class is now pretty much empty, but we might still need it for breakpoint support. R=titzer@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2522953002 Cr-Commit-Position: refs/heads/master@{#41316}
-
- 15 Nov, 2016 1 commit
-
-
clemensh authored
Before, we allocated one script per function per instance, and each script referenced the wasm instance and the function index. Now we only allocate one script per compiled wasm module, so the script also only references this WasmCompiledModule, which causes changes to many interfaces. Instead of fixing the disassemble API only used via debug.js, I decided to drop it for now. Some later CL will reintroduce it via DebugInterface. BUG=v8:5530,chromium:659715 R=yangguo@chromium.org, titzer@chromium.org CC=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2493823003 Cr-Commit-Position: refs/heads/master@{#41004}
-
- 14 Nov, 2016 1 commit
-
-
tebbi authored
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
-
- 26 Oct, 2016 1 commit
-
-
neis authored
R=adamk@chromium.org BUG= Review-Url: https://codereview.chromium.org/2452543003 Cr-Commit-Position: refs/heads/master@{#40584}
-
- 19 Oct, 2016 1 commit
-
-
titzer authored
R=clemensh@chromium.org,ahaas@chromium.org BUG= Review-Url: https://chromiumcodereview.appspot.com/2428343005 Cr-Commit-Position: refs/heads/master@{#40426}
-
- 14 Oct, 2016 1 commit
-
-
jgruber authored
'RETURN_RESULT(isolate, call, type)' is equivalent to 'return call' in all current use cases. BUG= Review-Url: https://codereview.chromium.org/2415993003 Cr-Commit-Position: refs/heads/master@{#40302}
-
- 12 Oct, 2016 1 commit
-
-
clemensh authored
For the asm.js to WASM pipeline, the current stack traces only show low-level WASM information. This CL maps this back to asm.js source positions. It does so by attaching the asm.js source Script to the compiled WASM module, and emitting a delta-encoded table which maps from WASM byte offsets to positions within that Script. As asm.js code does not throw exceptions, we only store a mapping for call instructions. The new AsmJsWasmStackFrame implementation inherits from WasmStackFrame, but contains the logic to provide the source script and the position inside of it. What is still missing is the JSFunction object returned by CallSite.getFunction(). We currently return null. R=jgruber@chromium.org, titzer@chromium.org BUG=v8:4203 Review-Url: https://codereview.chromium.org/2404253002 Cr-Commit-Position: refs/heads/master@{#40205}
-
- 30 Aug, 2016 1 commit
-
-
jgruber authored
This commit introduces several new types: * JSStackFrame and WasmStackFrame are wrapper classes around a single frame in a FrameArray. * They both inherit from StackFrameBase, which uses virtual dispatch to call the correct implementation. * FrameArrayIterator contains a static instance of JSStackFrame and WasmStackFrame and returns a pointer to the corresponding type for each frame. * The JS callsite object now contains the frame array and frame index as internal fields. Internal stack formatting now relies completely on FrameArrayIterator and the {JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom user formatting through Error.prepareStackTrace. BUG= Review-Url: https://codereview.chromium.org/2275233002 Cr-Commit-Position: refs/heads/master@{#39015}
-
- 24 Aug, 2016 2 commits
-
-
jgruber authored
This makes some information passed implicitly (e.g. the ForceConstructor flag used to be a special symbol passed as the receiver) explicit. BUG= Review-Url: https://codereview.chromium.org/2274823002 Cr-Commit-Position: refs/heads/master@{#38870}
-
jgruber authored
A FrameArray encodes information about a set of stack frames into a fixed array. This commit is a pure refactoring to make the structure of fixed array-encoded frames explicit. BUG= Review-Url: https://codereview.chromium.org/2270783002 Cr-Commit-Position: refs/heads/master@{#38852}
-
- 18 Aug, 2016 1 commit
-
-
jgruber authored
Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of https://codereview.chromium.org/2230953002/ ) Reason for revert: Performance regressions in Gameboy, Life, CodeLoad and others. See crbug.com/638210. Original issue's description: > Refactor data structures for simple stack traces > > Simple stack traces are captured through Isolate::CaptureSimpleStackTrace. > Captured frames are stored in a FixedArray, which in turn is stored as a > property (using a private symbol) on the error object itself. Actual formatting > of the textual stack trace is done lazily when the user reads the stack > property of the error object. > > This would involve many conversions back and forth between index-encoded raw > data (receiver, function, offset and code), JS CallSite objects, and C++ > CallSite objects. > > This commit refactors the C++ CallSite class into a Struct class called > StackTraceFrame, which is the new single point of truth frame information. > Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS > CallSite objects (now created only when the user specifies custom stack trace > formatting through Error.prepareStackTrace) internally only store a reference > to a StackTraceFrame. > > BUG= > > Committed: https://crrev.com/b4c1aefb9c369f1a33a6ca94a5de9b06ea4bf5c4 > Cr-Commit-Position: refs/heads/master@{#38645} TBR=yangguo@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review-Url: https://codereview.chromium.org/2252783007 Cr-Commit-Position: refs/heads/master@{#38700}
-
- 16 Aug, 2016 1 commit
-
-
jgruber authored
Simple stack traces are captured through Isolate::CaptureSimpleStackTrace. Captured frames are stored in a FixedArray, which in turn is stored as a property (using a private symbol) on the error object itself. Actual formatting of the textual stack trace is done lazily when the user reads the stack property of the error object. This would involve many conversions back and forth between index-encoded raw data (receiver, function, offset and code), JS CallSite objects, and C++ CallSite objects. This commit refactors the C++ CallSite class into a Struct class called StackTraceFrame, which is the new single point of truth frame information. Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS CallSite objects (now created only when the user specifies custom stack trace formatting through Error.prepareStackTrace) internally only store a reference to a StackTraceFrame. BUG= Review-Url: https://codereview.chromium.org/2230953002 Cr-Commit-Position: refs/heads/master@{#38645}
-
- 03 Aug, 2016 3 commits
-
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2206203002 Cr-Commit-Position: refs/heads/master@{#38294}
-
jgruber authored
A corresponding flag was added as well to help us find out what breaks when we do not clear pending exceptions on each JS entry. BUG=5259 Review-Url: https://codereview.chromium.org/2208663002 Cr-Commit-Position: refs/heads/master@{#38292}
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2206573002 Cr-Commit-Position: refs/heads/master@{#38289}
-
- 02 Aug, 2016 1 commit
-
-
cbruni authored
We no longer need NeanderObject, the only user left was the message listener machanism which could be replace by direct uses of FixedArrays. BUG=chromium:630217 Review-Url: https://codereview.chromium.org/2195243003 Cr-Commit-Position: refs/heads/master@{#38249}
-