- 05 Apr, 2017 1 commit
-
-
mtrofin authored
Better demarcation between what's mutable because it is code- specialization specific, and what is provided at initialization. BUG= Review-Url: https://codereview.chromium.org/2784233004 Cr-Commit-Position: refs/heads/master@{#44395}
-
- 31 Mar, 2017 2 commits
-
-
Clemens Hammacher authored
grow_memory was working from test cases, but not in combination with compiled code. This CL makes the effect of grow_memory executed either in the interpreter or compiled code always be reflected in both execution environments. It also adds a %RedirectToWasmInterpreter runtime function for testing this interaction. R=ahaas@chromium.org CC=gdeepti@chromium.org BUG=v8:5822 Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc Reviewed-on: https://chromium-review.googlesource.com/463506 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44297}
-
Clemens Hammacher authored
This CL cleans up a few things: - It removes two dead declarations: WasmMemoryObject::Grow and wasm::GrowInstanceMemory. - It removes the unneeded wasm::GetInstanceMemory function (use instance->memory_buffer() directly). - It moves wasm::GetInstanceMemorySize to WasmInstanceObject::GetMemorySize. - It moves wasm::GrowInstanceMemory to WasmInstanceObject::GrowMemory. - It moves wasm::GrowWebAssemblyMemory to WasmMemoryObject::Grow. R=ahaas@chromium.org CC=gdeepti@chromium.org Change-Id: I19781ca9784f1a8e7b60955bef82e341c4f75550 Reviewed-on: https://chromium-review.googlesource.com/463167 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#44293}
-
- 29 Mar, 2017 1 commit
-
-
mtrofin authored
The regression comes from attempting to serialize a module with memory requirements after instantiation - which is what happens in common emscripten scenarios, where the module is obtained from WebAssembly.instantiate(buffer). We then try and serialize the JSArrayBuffer representing the instance memory. That operation fails. Added regression test and also extended the test to cover the other 2 instance-specific values - globals and tables. Added a discussion on WasmCompiledModule (comments) explaining design decisions. BUG=chromium:705562 Review-Url: https://codereview.chromium.org/2784453002 Cr-Commit-Position: refs/heads/master@{#44250}
-
- 21 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
This CL makes the interpreter reentrant by allowing different activations to be live at the same time. The wasm interpreter keeps a list of activations and stores the stack height at the start of each activation. This information is used to unwind just one activation, or show the right portion of the interpreter stack for each interpreter entry frame. The WasmDebugInfo object stores a mapping from frame pointer (of the interpreter entry) to the activation id in order to identify the activation based on the physical interpreter entry frame. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb Reviewed-on: https://chromium-review.googlesource.com/453958 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43976}
-
- 20 Mar, 2017 3 commits
-
-
Clemens Hammacher authored
Before, we were redirecting each function to the interpreter by iterating all code and patching all call sites using this one function. The runtime was hence quadratic if all functions were redirected to the interpreter as done by the --wasm-interpret-all flag. This CL fixes this to only iterate the code once and redirecting an arbitrary number of function. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: Ia4f2e94a2468f9bef3035b599e1f8a18acf309da Reviewed-on: https://chromium-review.googlesource.com/455785 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43946}
-
Clemens Hammacher authored
If an exception is thrown and the wasm interpreter entry frame is unwound, also the internal frames in the interpreter need to be unwound. We did not do so before, leaving a corrupted internal state of the wasm interpreter. Thus reusing it would fail. This CL fixes this and adds a test which reenters a previously unwound wasm interpreter. It checks that this works and the correct stack is returned. This test also requires support for calling an imported function which throws, so this change is also included here. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82 Reviewed-on: https://chromium-review.googlesource.com/453938 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43937}
-
Clemens Hammacher authored
This CL adds general lazy compilation support to WebAssembly, according to the design described in the design doc (see referenced bug). It's not used currently, but I tested locally that all tests succeed if I enable it by default. With a later CL, we will enable lazy compilation by default for validate-asm: https://chromium-review.googlesource.com/451318 R=titzer@chromium.org, ahaas@chromium.org, bmeurer@chromium.org BUG=v8:5991 Change-Id: I85440382118a24fc245e78a5a90cf2b95659cd69 Reviewed-on: https://chromium-review.googlesource.com/451317 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43936}
-
- 17 Mar, 2017 2 commits
-
-
jgruber authored
Default to the chromium-internal build config (instead of the more permissive no_chromium_code config). BUG=v8:5878 Review-Url: https://codereview.chromium.org/2758563002 Cr-Commit-Position: refs/heads/master@{#43909}
-
titzer authored
This CL renames all occurrences of "internal field" to "embedder field" to prevent confusion. As it turns out, these fields are not internal to V8, but are actually embedder provided fields that should not be mucked with by the internal implementation of V8. Note that WASM does use these fields, and it should not. BUG=v8:6058 Review-Url: https://codereview.chromium.org/2741683004 Cr-Commit-Position: refs/heads/master@{#43900}
-
- 16 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
This behaviour was missing before. If a trap is encountered in the interpreter, we now throw the right error. With test. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2 Reviewed-on: https://chromium-review.googlesource.com/453839 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43859}
-
- 07 Mar, 2017 1 commit
-
-
Andreas Haas authored
Issue 6051 description: "Blink blindly assumes that it can get an aligned pointer from the 0-th internal field of any object that has two internal fields." R=titzer@chromium.org, jochen@chromium.org BUG=v8:6051 Change-Id: I814b76e508ffd9fe2326bd0e728129f2a013b807 Reviewed-on: https://chromium-review.googlesource.com/451319Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43653}
-
- 06 Mar, 2017 1 commit
-
-
kozyatinskiy authored
This CL provide type with each break location, type could be: call, return or debugger statement. BUG=chromium:432469 R=yangguo@chromium.org,dgozman@chromium.org Review-Url: https://codereview.chromium.org/2728563002 Cr-Commit-Position: refs/heads/master@{#43619}
-
- 21 Feb, 2017 2 commits
-
-
clemensh authored
Test the wasm interpreter entry stub by creating two wasm functions A and B, make A pass arguments to B, then redirect B to be executed in the interpreter. Test different number and types or arguments. BUG=v8:5822 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2651793003 Cr-Commit-Position: refs/heads/master@{#43353}
-
mtrofin authored
Native resources allocated by v8, as internal implementation detail, and held by a Foreign object, must be released when the Isolate is torn down. Example: wasm::WasmModule allocated by wasm compile, and held throughout the lifetime of the WebAssembly.Module object. This change: - Extends Managed<CppType> with a mechanism for doing just that - Separates the role of Managed<CppType> to be strictly an owner of the lifetime of the native resource. For cases where that's not desirable, we can polymorphically use Foregin. - moves managed.h out of wasm, since it's not wasm-specific. BUG=680065 Review-Url: https://codereview.chromium.org/2676513008 Cr-Commit-Position: refs/heads/master@{#43350}
-
- 14 Feb, 2017 1 commit
-
-
Andreas Haas authored
Within the initialization of a WasmInstanceWrapper a WeakCell is allocated for the wrapped instance. This allocation of the WeakCell can cause a garbage collection. The bug happened because a pointer to the WasmInstanceWrapper was stored in the unhandlified this pointer, which was invalidated by the garbage collection. R=clemensh@chromium.org CC=gdeepti@chromium.org BUG=chromium:691538 Change-Id: I7001ab7ad3ee30f4c87a13c42e2fd16c0c86027a Reviewed-on: https://chromium-review.googlesource.com/441766Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43177}
-
- 13 Feb, 2017 1 commit
-
-
Marja Hölttä authored
R=mstarzinger@chromium.org BUG=v8:5294 Change-Id: If2cdb4d38829e69ddd8aecb99c99c3a03050f57c Reviewed-on: https://chromium-review.googlesource.com/441824 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43158}
-
- 24 Jan, 2017 2 commits
-
-
clemensh authored
Implement stepping by remembering the current step action in the wasm interpreter handle in WasmDebugInfo, and using it when continuing execution in the interpreter. The control flow is as follows: After module compilation, the user sets a breakpoint in wasm. The respective function is redirected to the interpreter and the breakpoint is set on the interpreter. When it is hit, we notify all debug event listeners, which might prepare stepping. When returning from these listeners, before continuing execution, we check whether stepping was requested and continue execution in the interpreter accordingly. Stepping from Wasm to JS and vice versa will be implemented and tested in a follow-up CL. Testing this requires breakpoints and stepping in Wasm to be exposed via the inspector interface, such that we can write an inspector test. This mixed JS-Wasm-execution is hard to set up in a cctest. R=titzer@chromium.org, yangguo@chromium.org BUG= Review-Url: https://codereview.chromium.org/2649533002 Cr-Commit-Position: refs/heads/master@{#42624}
-
titzer authored
BUG=v8:5860 R=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2653533003 Cr-Commit-Position: refs/heads/master@{#42622}
-
- 20 Jan, 2017 1 commit
-
-
clemensh authored
Frame inspection is currently limited to locations of execution. Further details like local variables or stack content will follow later. The FrameInspector now stores a pointer to the interpreted wasm frame, and redirects certain requests there, just as for deoptimized frames. Hitting breakpoints is now also supported for wasm frames. R=yangguo@chromium.org, titzer@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2629823003 Cr-Commit-Position: refs/heads/master@{#42551}
-
- 18 Jan, 2017 2 commits
-
-
clemensh authored
Breakpoints are always re-set by the embedder after compilation, so we don't want to store the corresponding breakpoint objects. Also don't serialize WASM_INTERPRETER_ENTRY stubs as they are replaced by ordinary WASM_FUNCTION code at instantiation anyway, and skip WASM_TO_JS wrappers which are recompiled on each instantiation. Instead, we serialize the Illegal builtin, and also use that one instead of the placeholder when compiling the wasm code initially. R=titzer@chromium.org, yangguo@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2629853004 Cr-Commit-Position: refs/heads/master@{#42451}
-
clemensh authored
Store breakpoint positions in the WasmSharedModuleData in order to set them on new instantiations. Also redirect them to all live instances at the time the breakpoint is set. Inside the WasmDebugInfo, we store the BreakPointInfo objects to find hit breakpoints. R=titzer@chromium.org, yangguo@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2626253002 Cr-Commit-Position: refs/heads/master@{#42443}
-
- 17 Jan, 2017 1 commit
-
-
titzer authored
R=rossberg@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2636173002 Cr-Commit-Position: refs/heads/master@{#42426}
-
- 15 Jan, 2017 1 commit
-
-
gdeepti authored
- Table.Grow updates function, signature table sizes - Updates generated code with new base addresses for function, signature tables - Relocates size references for correct bounds check R=bradnelson@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2637643002 Cr-Commit-Position: refs/heads/master@{#42349}
-
- 13 Jan, 2017 1 commit
-
-
clemensh authored
If a breakpoint is set on a wasm function, compile an interpreter entry stub for it, and replace all calls to the original function by calls to this interpreter entry. Also, instantiate a wasm interpreter object on demand and set the breakpoint there. R=titzer@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2625093004 Cr-Commit-Position: refs/heads/master@{#42309}
-
- 12 Jan, 2017 1 commit
-
-
clemensh authored
Wasm frames can be either compiled or interpreted. For interpreted wasm frames, there is only one physical stack frame representing an arbitrary stack of interpreted functions. Hence the physical stack frame needs to provide a summary of the underlying functions. Summaries were tailored for JavaScript frames before. Now they are universal. The refactored FrameSummaries are now also used in the FrameInspector, and from the StackFrame objects themselves, to avoid code duplication. All dispatch is implemented "manually", making the FrameSummary still stack-allocatable. BUG=v8:5822 R=yangguo@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2619353006 Cr-Commit-Position: refs/heads/master@{#42279}
-
- 11 Jan, 2017 1 commit
-
-
clemensh authored
Also, add a runtime function to call the interpreter, passing a stack-allocated buffer holding the arguments. The WASM_INTERPRETER_ENTRY stub allocates the stack slot for the arguments, fills it, and calls to the wasm interpreter. It's abi is compatible with WASM functions, such that we can just replace a call to a WASM_FUNCTION with a call to WASM_INTERPRETER_ENTRY. See tracking bug to get the overall picture. BUG=v8:5822 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2619803004 Cr-Commit-Position: refs/heads/master@{#42242}
-
- 10 Jan, 2017 1 commit
-
-
gdeepti authored
- Refactor Dispatch tables to have separate function, signature tables - New Relocation type for WasmFunctionTableReference, assembler, compiler support. - RelocInfo helper functions for Wasm references Review-Url: https://codereview.chromium.org/2627543003 Cr-Commit-Position: refs/heads/master@{#42192}
-
- 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 2 commits
-
-
clemensh authored
This CL implements GetPossibleBreakpoints for wasm, by iterating over all functions in the requested range and returning the location of all instructions within that range. The connection to the inspector will be added later, when setting breakpoint also works for wasm: http://crrev.com/2536763002 BUG=chromium:613110 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2588763002 Cr-Commit-Position: refs/heads/master@{#41818}
-
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}
-
- 09 Dec, 2016 2 commits
-
-
clemensh authored
We should really think about having a static analysis to check for such errors, and a bot executing it regularly. This is not the first time I encounter declared functions that are never defined. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2561333002 Cr-Commit-Position: refs/heads/master@{#41617}
-
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}
-
- 06 Dec, 2016 1 commit
-
-
titzer authored
R=bradnelson@chromium.org,rossberg@chromium.org BUG=v8:5705 Review-Url: https://codereview.chromium.org/2551323003 Cr-Commit-Position: refs/heads/master@{#41530}
-
- 05 Dec, 2016 1 commit
-
-
clemensh authored
This CL adds a new header src/debug/interface-types.h, moves the definition of Location from the debug-interface.h to this new header, and adds a new definition for the WasmDisassembly types. This allows to use the types in other implementation files or headers without having to include the entire debug-interface.h, reducing build dependencies and compile time (especially for incremental builds). The WasmDisassembly type replaces the old std::pair<std::string, std::vector<std::tuple<...>>>, which was a bit hard to unravel. R=yangguo@chromium.org, kozyatinskiy@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2529383002 Cr-Commit-Position: refs/heads/master@{#41488}
-
- 01 Dec, 2016 1 commit
-
-
clemensh authored
Before, it was a method in wasm namespace, and received a Handle<WasmCompiledModule>. As it does not allocate on the heap, we can just make it a non-static method on WasmCompiledModule. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2536373007 Cr-Commit-Position: refs/heads/master@{#41429}
-
- 30 Nov, 2016 1 commit
-
-
eholk authored
During codegen, we build a list mapping protected instructions to their associated landing pads. This will ultimately by used by the signal handler to recover from out of bounds faults and throw a JS exception. This is mostly pulled from my larger in-progress CL at https://codereview.chromium.org/2371833007/. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2500443004 Cr-Commit-Position: refs/heads/master@{#41400}
-
- 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}
-