1. 16 Sep, 2016 2 commits
  2. 12 Sep, 2016 3 commits
  3. 01 Sep, 2016 1 commit
  4. 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
  5. 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
  6. 12 Aug, 2016 1 commit
    • yangguo's avatar
      [debugger] separate break point info from code instrumentation. · b8c05042
      yangguo authored
      Previously, we would both instrument the code, and add/remove
      BreakPointInfo objects through BreakLocation. This is bad design and
      unsuitable for having two different code kinds.
      
      We would now add/remove BreakPointInfo objects, and use that as source
      of truth when instrumenting the code. If we have both bytecode and FCG
      code, we would simply apply these break points twice to either.
      
      Notable changes:
      - Removed many functionality from BreakLocation.
      - Instrumentation (patching code for breaks) happens by applying break
        point info onto code.
      - Instrumentation (code patching) is done by the BreakIterator. For
        bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's
        CodeBreakIterator.
      - Changes to code instrumentation mostly involves clearing current
        instrumentation and then (re-)applying break points.
      - DebugInfo can now reference both bytecode and FCG code.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5265
      
      Review-Url: https://codereview.chromium.org/2238893002
      Cr-Commit-Position: refs/heads/master@{#38596}
      b8c05042
  7. 10 Aug, 2016 1 commit
  8. 12 Jul, 2016 2 commits
  9. 01 Jul, 2016 2 commits
    • littledan's avatar
      Implement immutable prototype chains · 0ff7b483
      littledan authored
      This patch implements "immutable prototype exotic objects" from the ECMAScript
      spec, which are objects whose __proto__ cannot be changed, but are not otherwise
      frozen. They are introduced in order to prevent a Proxy from being introduced
      to the prototype chain of the global object.
      
      The API is extended by a SetImmutablePrototype() call in ObjectTemplate, which
      can be used to vend new immutable prototype objects. Additionally, Object.prototype
      is an immutable prototype object.
      
      In the implementation, a new bit is added to Maps to say whether the prototype is
      immutable, which is read by SetPrototype. Map transitions to the immutable prototype
      state are not saved in the transition tree because the main use case is just for
      the prototype chain of the global object, which there will be only one of per
      Context, so no need to take up the extra word for a pointer in each full transition
      tree.
      
      BUG=v8:5149
      
      Review-Url: https://codereview.chromium.org/2108203002
      Cr-Commit-Position: refs/heads/master@{#37482}
      0ff7b483
    • bradnelson's avatar
      Hooking up asm-wasm conversion. · f20323dc
      bradnelson authored
      Directs 'use asm' traffic through asm-wasm conversion when --validate-asm is passed.
      
      Adds a builtin that handles the fallback to JS.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
      TEST=asm-wasm
      R=mstarzinger@chromium.org,titzer@chromium.org
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2057403003
      Cr-Commit-Position: refs/heads/master@{#37470}
      f20323dc
  10. 28 Jun, 2016 2 commits
  11. 27 Jun, 2016 1 commit
  12. 23 Jun, 2016 3 commits
  13. 21 Jun, 2016 2 commits
  14. 14 Jun, 2016 2 commits
  15. 13 Jun, 2016 2 commits
  16. 08 Jun, 2016 1 commit
  17. 06 Jun, 2016 1 commit
  18. 27 May, 2016 1 commit
  19. 03 May, 2016 1 commit
  20. 28 Apr, 2016 1 commit
  21. 20 Apr, 2016 2 commits
  22. 19 Apr, 2016 1 commit
  23. 12 Apr, 2016 1 commit
    • hlopko's avatar
      Use EmbedderHeapTracer instead of object grouping when embedder sets the heap tracer. · 6d1f7282
      hlopko authored
      When the embedder sets the heap tracer, V8, during marking, will collect all reachable wrappers, and then ask embedder to trace its heap. The embedder is expected to call PersistentBase::RegisterExternalReference with all wrappers reachable from the given ones. This fixed point iteration happens in MarkCompact::ProcessEphemeralMarking.
      
      For more efficient object visiting during marking, we need a special JS_API_OBJECT_TYPE (in tandem with already existing JS_SPECIAL_API_OBJECT_TYPE) and corresponding visitor (JSApiObjectVisitor).
      
      BUG=chromium:468240
      LOG=no
      
      Review URL: https://codereview.chromium.org/1844413002
      
      Cr-Commit-Position: refs/heads/master@{#35412}
      6d1f7282
  24. 06 Apr, 2016 1 commit
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.
      
      This CL additionally deletes some dead IC code.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1846963002
      
      Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
  25. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored
      This change introduces wide prefix bytecodes to support wide (16-bit)
      and extra-wide (32-bit) operands. It retires the previous
      wide-bytecodes and reduces the number of operand types.
      
      Operands are now either scalable or fixed size. Scalable operands
      increase in width when a bytecode is prefixed with wide or extra-wide.
      
      The bytecode handler table is extended to 256*3 entries. The
      first 256 entries are used for bytecodes with 8-bit operands,
      the second 256 entries are used for bytecodes with operands that
      scale to 16-bits, and the third group of 256 entries are used for
      bytecodes with operands that scale to 32-bits.
      
      LOG=N
      BUG=v8:4747,v8:4280
      
      Review URL: https://codereview.chromium.org/1783483002
      
      Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  26. 16 Mar, 2016 1 commit
    • mstarzinger's avatar
      Introduce "optimized_out" oddball marker for compilers. · eee34dd5
      mstarzinger authored
      This introduces {optimized_out} as another Oddball kind to be used by
      optimizing compilers when values are being optimized away. The aim is
      providing visibility when this value leaks into the application domain.
      Currently this will lead to {undefined} values appearing which then
      silently propagate through the application. The special oddball can be
      identified easily as a bug and also the debugger can treat it specially
      when needed.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1810483002
      
      Cr-Commit-Position: refs/heads/master@{#34817}
      eee34dd5
  27. 04 Mar, 2016 1 commit
  28. 03 Mar, 2016 1 commit