1. 16 Jun, 2017 1 commit
  2. 12 Jun, 2017 2 commits
  3. 09 Jun, 2017 1 commit
  4. 06 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
  5. 22 May, 2017 1 commit
  6. 11 May, 2017 1 commit
  7. 14 Apr, 2017 1 commit
  8. 24 Mar, 2017 1 commit
  9. 17 Mar, 2017 1 commit
  10. 16 Mar, 2017 2 commits
  11. 14 Mar, 2017 1 commit
  12. 13 Jan, 2017 1 commit
  13. 09 Jan, 2017 1 commit
  14. 20 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmSharedModuleData and refactor other objects · 081ac370
      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}
      081ac370
  15. 19 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      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}
      21a85c4a
  16. 12 Dec, 2016 3 commits
    • bradnelson's avatar
      [wasm] [asmjs] Route asm.js warnings to the dev console. · aabbbec6
      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}
      aabbbec6
    • clemensh's avatar
      [wasm] Provide correct eval origin for asm.js code · c4057d46
      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}
      c4057d46
    • clemensh's avatar
      [wasm] Generate correct locations for error messages · 222541df
      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}
      222541df
  17. 09 Dec, 2016 2 commits
    • yangguo's avatar
      [perf-prof] fix crash when logging. · 75f52005
      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}
      75f52005
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 890d28f3
      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}
      890d28f3
  18. 08 Dec, 2016 2 commits
    • clemensh's avatar
      Revert of [wasm] Fix location for error in asm.js ToNumber conversion... · d3d12541
      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}
      d3d12541
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 94cd46b5
      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}
      94cd46b5
  19. 28 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Move asm.js offset table to compiled module · 916a5337
      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}
      916a5337
  20. 15 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Allocate a single script per wasm module · 32077e01
      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}
      32077e01
  21. 14 Nov, 2016 1 commit
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      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}
      c3a6ca68
  22. 26 Oct, 2016 1 commit
  23. 19 Oct, 2016 1 commit
  24. 14 Oct, 2016 1 commit
  25. 12 Oct, 2016 1 commit
    • clemensh's avatar
      [wasm] Provide better stack traces for asm.js code · 5d9fa102
      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}
      5d9fa102
  26. 30 Aug, 2016 1 commit
    • jgruber's avatar
      Refactor call site handling for stack formatting · f7bc1fc7
      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}
      f7bc1fc7
  27. 24 Aug, 2016 2 commits
  28. 18 Aug, 2016 1 commit
    • jgruber's avatar
      Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of... · 6b7493a4
      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}
      6b7493a4
  29. 16 Aug, 2016 1 commit
    • jgruber's avatar
      Refactor data structures for simple stack traces · b4c1aefb
      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}
      b4c1aefb
  30. 03 Aug, 2016 3 commits
  31. 02 Aug, 2016 1 commit