1. 02 Dec, 2016 1 commit
  2. 29 Nov, 2016 1 commit
  3. 28 Nov, 2016 1 commit
  4. 04 Nov, 2016 1 commit
  5. 18 Oct, 2016 1 commit
    • caitp's avatar
      [builtins] implement Array.prototype[@@iterator] in TFJ builtins · 86d0dd36
      caitp authored
      Implements the variations of CreateArrayIterator() in TFJ builtins
      (ArrayPrototypeValues, ArrayPrototypeEntries and ArrayPrototypeKeys), and
      provides two new Object types with numerous maps which identify certain
      behaviours, which will be useful for inlining.
      
      Removes src/js/array-iterator.js entirely
      
      Also adds support for printing Symbol literals inserted by the Parser during
      desugaring when FLAG_print_builtin_ast is set to true.
      
      BUG=v8:5388
      R=bmeurer@chromium.org, cbruni@chromium.org
      TBR=ulan@chromium.org
      
      Review-Url: https://codereview.chromium.org/2405253006
      Cr-Commit-Position: refs/heads/master@{#40373}
      86d0dd36
  6. 13 Oct, 2016 2 commits
  7. 12 Oct, 2016 2 commits
  8. 07 Oct, 2016 1 commit
  9. 21 Sep, 2016 2 commits
  10. 16 Sep, 2016 1 commit
  11. 02 Sep, 2016 1 commit
    • mvstanton's avatar
      Forking the type system between Crankshaft & Turbofan. · 17e9e2f4
      mvstanton authored
      Our Type class has a semantic and representational dimension.
      Much code in src/ast, Crankshaft and Turbofan is based on it.
      Going forward in Turbofan we'd like to remove representational information
      entirely. To that end, new type AstType has been created to preserve
      existing behavior for the benefit of Crankshaft and the AST.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2302283002
      Cr-Commit-Position: refs/heads/master@{#39135}
      17e9e2f4
  12. 01 Sep, 2016 1 commit
  13. 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
  14. 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
  15. 10 Aug, 2016 1 commit
  16. 23 Jun, 2016 1 commit
  17. 10 May, 2016 1 commit
  18. 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
  19. 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
  20. 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
  21. 04 Mar, 2016 1 commit
  22. 03 Mar, 2016 1 commit
  23. 02 Mar, 2016 1 commit
    • verwaest's avatar
      Speed up the LookupIterator · 2608ecc7
      verwaest authored
      This introduces a new instance type and reorders the JSObject types so any type requiring special LookupIterator support can be identified with a single range check.
      
      In addition, it restructures the Next for better performance, avoiding unnecessary calls.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1751043002
      
      Cr-Commit-Position: refs/heads/master@{#34429}
      2608ecc7
  24. 27 Feb, 2016 1 commit
  25. 26 Feb, 2016 1 commit
  26. 24 Feb, 2016 1 commit
    • bmeurer's avatar
      [compiler] Drop the CompareNilIC. · 666aec03
      bmeurer authored
      Since both null and undefined are also marked as undetectable now, we
      can just test that bit instead of having the CompareNilIC try to collect
      feedback to speed up the general case (without the undetectable bit
      being used).
      
      Drive-by-fix: Update the type system to match the new handling of
      undetectable in the runtime.
      
      R=danno@chromium.org
      
      Review URL: https://codereview.chromium.org/1722193002
      
      Cr-Commit-Position: refs/heads/master@{#34237}
      666aec03
  27. 16 Feb, 2016 1 commit
  28. 08 Feb, 2016 1 commit
  29. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  30. 27 Jan, 2016 1 commit
  31. 26 Jan, 2016 1 commit
    • jarin's avatar
      Replace HeapType with a non-templated FieldType class. · cfaeb63b
      jarin authored
      This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
      
      The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
      
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1636013002
      
      Cr-Commit-Position: refs/heads/master@{#33521}
      cfaeb63b
  32. 25 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored
      Cleanup %ForInPrepare runtime entry, and unify common logic with
      %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
      a TupleType to properly type JSForInPrepare and its projections w/o
      special hacks in the Typer. And fix %ForInNext and JSForInNext to be
      consistent with fullcodegen again (after the proxy refactorings last
      quarter).
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1631583002
      
      Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
  33. 18 Jan, 2016 1 commit
  34. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  35. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  36. 04 Dec, 2015 1 commit