1. 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
  2. 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
  3. 10 Aug, 2016 1 commit
  4. 28 Jul, 2016 1 commit
  5. 27 Jul, 2016 1 commit
  6. 26 Jul, 2016 3 commits
  7. 25 Jul, 2016 1 commit
  8. 13 Jul, 2016 1 commit
  9. 07 Jul, 2016 1 commit
    • ishell's avatar
      [runtime] Better encapsulation of dictionary objects handling in lookup iterator. · 3fbb4521
      ishell authored
      Now LookupIterator follows the same pattern of prepare transition, apply transition
      and write value when adding new properties to dictionary objects.
      
      JSGlobalObject case:
      * Prepare transition phase ensures that there is a "transition" property cell
        prepared for receiving a value.
      * Apply transition phase does nothing.
      * Prepare for data property phase ensures that the existing property cell can
        receive the value.
      * Write value phase writes value directly to the current property cell.
      
      JSObject case:
      * Prepare transition phase prepares the object for receiving a data value (which
        could switch an object to dictionary mode).
      * Apply transition phase migrates object to a transition map. If the map happened
        to be a dictionary mode object's map then an uninitialized entry added to the
        properties dictionary.
      * Prepare for data property phase does nothing.
      * Write value phase just puts value to the properties dictionary.
      
      BUG=chromium:576312
      
      Review-Url: https://codereview.chromium.org/2127583002
      Cr-Commit-Position: refs/heads/master@{#37585}
      3fbb4521
  10. 01 Jul, 2016 1 commit
    • 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
  11. 28 Jun, 2016 1 commit
  12. 27 Jun, 2016 2 commits
  13. 24 Jun, 2016 1 commit
  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. 02 Jun, 2016 1 commit
  19. 01 Jun, 2016 2 commits
  20. 31 May, 2016 1 commit
    • littledan's avatar
      [esnext] Fix various callsites to use is_resumable, not is_generator · 46253e74
      littledan authored
      Async functions are built out of generators, but the
      SharedFunctionInfo returns false for is_generator. is_resumable is
      the broader query. This patch fixes many parts of V8 to refer
      to is_resumable as appropriate.
      
      One incidental change is to remove a check for generators extending
      classes. This is part of a general check for constructors being the
      only thing which can extend classes, so it is removed here and the
      error message for the general case is made more accurate.
      
      BUG=v8:4483
      
      Review-Url: https://codereview.chromium.org/1996943002
      Cr-Commit-Position: refs/heads/master@{#36621}
      46253e74
  21. 27 May, 2016 2 commits
  22. 24 May, 2016 1 commit
  23. 22 Apr, 2016 1 commit
  24. 20 Apr, 2016 2 commits
  25. 19 Apr, 2016 1 commit
  26. 18 Apr, 2016 1 commit
  27. 14 Apr, 2016 2 commits
  28. 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
  29. 07 Apr, 2016 1 commit
  30. 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
  31. 05 Apr, 2016 1 commit