1. 17 Jun, 2019 1 commit
  2. 11 Jun, 2019 1 commit
  3. 29 May, 2019 1 commit
  4. 28 May, 2019 1 commit
  5. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored
      This is a reland of 4b86fea5 with
      copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
      (bug led to holes in new space, which was crashing reproducibly
      on the ia32 bot).
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      >
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      >
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      >
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      >
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      Tbr: petermarshall@chromium.org
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored
      This reverts commit 4b86fea5.
      
      Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      > 
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      > 
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      > 
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      > 
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org
      
      Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored
      As the next step in supporting huge typed arrays in V8, this moves the
      external/data pointer from the FixedTypedArrayBase backing store to the
      JSTypedArray instance itself, and replaces the special backing stores
      with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      class hierarchy). By doing so, we can drastically simplify the system
      around typed arrays.
      
      Note: Several places in the code base used to check the instance type
      of the elements backing store of a JSTypedArray instead of checking the
      elements kind on the JSTypedArray map directly. Those had to be fixed,
      since the backing store is now always a ByteArray.
      
      Drive-by-fix: Move all the typed elements access related code into the
      elements.cc file to properly encapsulate the accesses.
      
      Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  6. 23 May, 2019 3 commits
    • Benedikt Meurer's avatar
      [cleanup] Remove the `Map::IsDictionaryMap()` method. · 5b46f573
      Benedikt Meurer authored
      There's a `Map::IsDictionaryMap()` method in addition to the
      `Map::is_dictionary_map()`, which apparently do very different things:
      The former checks whether the instance type of the Map is in a certain
      range (FIRST_DICTIONARY_TYPE to LAST_DICTIONARY_TYPE), while the latter
      checks the `is_dictionary_map` bit (which means that the backing store
      for the properties of a JSObject is in slow mode). To make matters worse
      there's also `CodeStubAssembler::IsDictionaryMap()`, which does the bit
      check similar to `Map::is_dictionary_map()`. And to make matters even
      worse the FIRST_DICTIONARY_TYPE to LAST_DICTIONARY_TYPE range also
      contains instance types for classes that aren't subclass of `Dictionary`
      (despite a comment stating the opposite).
      
      So in conclusion it's best to remove the confusing
      `Map::IsDictionaryMap()` method, which is anyways wrong, and just test
      explicitly for `NameDictionary`, `NumberDictionary` or
      `GlobalDictionary` in the appropriate places.
      
      Bug: v8:9183
      Change-Id: If35f73261e3cc96938ebf499bf32be3ec725288b
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627330
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61770}
      5b46f573
    • Yang Guo's avatar
      Move more relevant files to src/objects · a0c37974
      Yang Guo authored
      TBR=bmeurer@chromium.org,leszeks@chromium.org
      
      Bug: v8:9247
      Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61769}
      a0c37974
    • Clemens Hammacher's avatar
      [cleanup] Avoid {Object::operator->} · 878ccb33
      Clemens Hammacher authored
      This CL was generated by an automatic clang AST rewriter using this
      matcher expression:
      
        callExpr(
          callee(
            cxxMethodDecl(
              hasName("operator->"),
              ofClass(isSameOrDerivedFrom("v8::internal::Object"))
            )
          ),
          argumentCountIs(1)
        )
      
      The "->" at the expression location was then rewritten to ".".
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
      
      Bug: v8:9183, v8:3770
      No-Try: true
      No-Tree-Checks: true
      Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61764}
      878ccb33
  7. 21 May, 2019 2 commits
  8. 20 May, 2019 1 commit
  9. 15 May, 2019 2 commits
    • Toon Verwaest's avatar
      [json] Preallocate mutable heap numbers so object verification doesn't fail · a7985022
      Toon Verwaest authored
      Additionally pass WriteBarrierMode while building the object
      
      Change-Id: Ibc8ad592f822ee3b046406013cc36ae64f6b099b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613251Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61547}
      a7985022
    • Toon Verwaest's avatar
      [json] Make json parsing iterative · 4b60b40a
      Toon Verwaest authored
      This avoids the need to throw range errors when we run out of stack, limiting
      us only by available memory.
      
      The main parser loop is implemented by two subloops.
      
      The first subloop finishes whenever it generates primitive values, empty
      arrays, or empty objects. If a non-empty object or array is started, the loop
      continues to parse its first member.
      
      The second subloop consumes produced values and either adds them to the parent
      array or object, or returns it. The second loop finishes whenever a next value
      needs to be produced. When the loop itself produces a finished array or object,
      the loop continues.
      
      Exceptions are handled by moving the cursor to end-of-input. Upon end-of-input,
      the first loop sets the continuation to "kFail". That causes the second loop to
      tear down continuation stack and related handle scopes, resulting in an empty
      handle.
      
      The CL additionally buffers all named properties and elements so we can
      immediately allocate a correctly shaped object. For object elements we'll take
      flat array or dictionary encoding depending on what is more efficient.
      
      This means that element handles are now allocated in their parent HandleScope,
      rather than having local handlescopes per-property (of big objects); which is
      why I've adjusted the handle-count test to not allocate as many properties. In
      the future it would be nice to not have to allocate (as many) handles since
      almost everything in the JSON graph will survive JSON parsing...
      
      Bug: chromium:710383
      Change-Id: Ia3a7fd0ac260fb1c0e5f929276792b2f8e5fc0ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609802Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61533}
      4b60b40a
  10. 10 May, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland "[compiler] Don't collect source positions for the top frame"" · bf9e3e4d
      Dan Elphick authored
      This is a reland of f2e65226
      
      Nothing has changed but
      https://chromium-review.googlesource.com/c/v8/v8/+/1585269 has been rolled
      back due to v8:9234.
      
      Original change's description:
      > Reland "[compiler] Don't collect source positions for the top frame"
      >
      > Fixed crashes by adding missing call to EnsureSourcePositionsAvailable,
      > which requires clearing and restoring the pending exception.
      >
      > > While most source positions were not collected even throwing exceptions,
      > > the top frame still was always collected as it was used to initialize
      > > the JSMessageObject. This skips even that frame, by storing the
      > > SharedFunctionInfo and bytecode offset in the JSMessageObject allowing
      > > it to lazily evaluate the actual source position.
      > >
      > > Also adds tests to test-api.cc that test each of the source position
      > > functions in isolation to ensure that they don't rely on previous
      > > invocations to call the source collection function.
      > >
      > > Since no source positions are now collected at the point when an
      > > exception is thrown, the mjsunit/stack-traces-overflow now passes again
      > > with the flag enabled. (cctest/test-cpu-profiler/Inlining2 is now the
      > > only failure).
      >
      > Bug: v8:8510
      > Change-Id: Ifa5fe31d3db34a6c6d6a9cef3d646ad620dabd81
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601270
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61372}
      
      TBR=ulan@chromium.org
      
      Bug: v8:8510
      Change-Id: Iaa9e376f90d10c0f25d1bcc352808363e4ea8b4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605946Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61418}
      bf9e3e4d
  11. 09 May, 2019 2 commits
    • Maya Lekova's avatar
      Revert "Reland "[compiler] Don't collect source positions for the top frame"" · 9dff517a
      Maya Lekova authored
      This reverts commit f2e65226.
      
      Reason for revert: Speculative revert, seems to break GC stress bot and block LKGR - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/25701
      
      Original change's description:
      > Reland "[compiler] Don't collect source positions for the top frame"
      > 
      > Fixed crashes by adding missing call to EnsureSourcePositionsAvailable,
      > which requires clearing and restoring the pending exception.
      > 
      > > While most source positions were not collected even throwing exceptions,
      > > the top frame still was always collected as it was used to initialize
      > > the JSMessageObject. This skips even that frame, by storing the
      > > SharedFunctionInfo and bytecode offset in the JSMessageObject allowing
      > > it to lazily evaluate the actual source position.
      > >
      > > Also adds tests to test-api.cc that test each of the source position
      > > functions in isolation to ensure that they don't rely on previous
      > > invocations to call the source collection function.
      > >
      > > Since no source positions are now collected at the point when an
      > > exception is thrown, the mjsunit/stack-traces-overflow now passes again
      > > with the flag enabled. (cctest/test-cpu-profiler/Inlining2 is now the
      > > only failure).
      > 
      > Bug: v8:8510
      > Change-Id: Ifa5fe31d3db34a6c6d6a9cef3d646ad620dabd81
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601270
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61372}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,delphick@chromium.org
      
      Change-Id: Ie590df6c308b38836afc5d417d03d2a63260bcb2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8510
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1602692Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61381}
      9dff517a
    • Dan Elphick's avatar
      Reland "[compiler] Don't collect source positions for the top frame" · f2e65226
      Dan Elphick authored
      Fixed crashes by adding missing call to EnsureSourcePositionsAvailable,
      which requires clearing and restoring the pending exception.
      
      > While most source positions were not collected even throwing exceptions,
      > the top frame still was always collected as it was used to initialize
      > the JSMessageObject. This skips even that frame, by storing the
      > SharedFunctionInfo and bytecode offset in the JSMessageObject allowing
      > it to lazily evaluate the actual source position.
      >
      > Also adds tests to test-api.cc that test each of the source position
      > functions in isolation to ensure that they don't rely on previous
      > invocations to call the source collection function.
      >
      > Since no source positions are now collected at the point when an
      > exception is thrown, the mjsunit/stack-traces-overflow now passes again
      > with the flag enabled. (cctest/test-cpu-profiler/Inlining2 is now the
      > only failure).
      
      Bug: v8:8510
      Change-Id: Ifa5fe31d3db34a6c6d6a9cef3d646ad620dabd81
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601270
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61372}
      f2e65226
  12. 08 May, 2019 1 commit
  13. 07 May, 2019 3 commits
    • Z Duong Nguyen-Huu's avatar
      Add new frozen, sealed holey elements kind · daa62d4f
      Z Duong Nguyen-Huu authored
      This is the follow-up for frozen, sealed packed elements kind.
      Design docs: bit.ly/fast-frozen-sealed-elements-in-v8
      This change is only support the transition from holey elements to holey sealed elements (via object.seal) or to holey frozen elements (via object.freeze).
      Added tests for non-extensible, sealed, frozen holey elements in https://chromium-review.googlesource.com/c/v8/v8/+/1574503 and https://chromium-review.googlesource.com/c/v8/v8/+/1582481
      
      Bug: v8:6831
      Change-Id: Ia4373648f79f2ebebb390982a503145844a0c123
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574777
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61307}
      daa62d4f
    • Dan Elphick's avatar
      Revert "[compiler] Don't collect source positions for the top frame" · 4bb78818
      Dan Elphick authored
      This reverts commit 758700a7.
      
      Reason for revert: Broken
      
      Original change's description:
      > [compiler] Don't collect source positions for the top frame
      > 
      > While most source positions were not collected even throwing exceptions,
      > the top frame still was always collected as it was used to initialize
      > the JSMessageObject. This skips even that frame, by storing the
      > SharedFunctionInfo and bytecode offset in the JSMessageObject allowing
      > it to lazily evaluate the actual source position.
      > 
      > Also adds tests to test-api.cc that test each of the source position
      > functions in isolation to ensure that they don't rely on previous
      > invocations to call the source collection function.
      > 
      > Since no source positions are now collected at the point when an
      > exception is thrown, the mjsunit/stack-traces-overflow now passes again
      > with the flag enabled. (cctest/test-cpu-profiler/Inlining2 is now the
      > only failure).
      > 
      > Bug: v8:8510
      > Change-Id: Ic5382bdbab65cd8838f0c84b544fabb1a9109d13
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587385
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61271}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,delphick@chromium.org
      
      Change-Id: I3ee0b5db5f8a1b3255f68070dc10d27d0e013048
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8510
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598758Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61273}
      4bb78818
    • Dan Elphick's avatar
      [compiler] Don't collect source positions for the top frame · 758700a7
      Dan Elphick authored
      While most source positions were not collected even throwing exceptions,
      the top frame still was always collected as it was used to initialize
      the JSMessageObject. This skips even that frame, by storing the
      SharedFunctionInfo and bytecode offset in the JSMessageObject allowing
      it to lazily evaluate the actual source position.
      
      Also adds tests to test-api.cc that test each of the source position
      functions in isolation to ensure that they don't rely on previous
      invocations to call the source collection function.
      
      Since no source positions are now collected at the point when an
      exception is thrown, the mjsunit/stack-traces-overflow now passes again
      with the flag enabled. (cctest/test-cpu-profiler/Inlining2 is now the
      only failure).
      
      Bug: v8:8510
      Change-Id: Ic5382bdbab65cd8838f0c84b544fabb1a9109d13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587385
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61271}
      758700a7
  14. 16 Apr, 2019 1 commit
  15. 12 Apr, 2019 2 commits
  16. 11 Apr, 2019 1 commit
  17. 09 Apr, 2019 1 commit
  18. 01 Apr, 2019 2 commits
  19. 25 Mar, 2019 2 commits
  20. 12 Mar, 2019 1 commit
  21. 06 Mar, 2019 1 commit
  22. 04 Mar, 2019 1 commit
  23. 25 Feb, 2019 1 commit
  24. 15 Feb, 2019 1 commit
  25. 13 Feb, 2019 2 commits
  26. 09 Feb, 2019 1 commit
  27. 04 Feb, 2019 1 commit
    • Takuto Ikuta's avatar
      Reland "Reland "Extract JSObject class from objects.cc"" · bddc6aa5
      Takuto Ikuta authored
      This is a reland of 83908b86
      
      Fix: check V8_INTL_SUPPORT macro in js-objects.cc
      
      Original change's description:
      > Reland "Extract JSObject class from objects.cc"
      >
      > This is a reland of b8c821f4
      >
      > Fix: include src/string-stream.h for compile failure
      > https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20builder/39320
      >
      > Original change's description:
      > > Extract JSObject class from objects.cc
      > >
      > > I extracted following class member functions to js-objects.cc
      > > * JSReceiver
      > > * JSObject
      > > * JSBoundFunction
      > > * JSFunction
      > > * JSGlobalObject
      > > * JSDate
      > > * JSMessageObject
      > >
      > > Declaration of all above class are in js-objects.h.
      > >
      > > I also moved AllocationSite::DigestTransitionFeedback used in JSObject::UpdateAllocationSite
      > > and ShouldConvertToSlowElements used in JSObject and JSArray
      > >
      > > This patch makes compile time of objects.cc from 17.6s to 14.1s on Z840 Linux.
      > > And js-objects.cc takes 8.69s for compile.
      > >
      > > Bug: v8:7629
      > > Change-Id: I989f22363667445dd28d7f8c06c81ff79d6ed45f
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1447916
      > > Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59288}
      >
      > Bug: v8:7629
      > Bug: v8:8562
      > Change-Id: Iac2227c5f0c5a4072d16814ecae481fb4720e4f5
      > Reviewed-on: https://chromium-review.googlesource.com/c/1449951
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59318}
      
      Bug: v8:7629, v8:8562
      Change-Id: If8870bd579d8597d08981a83492f60595e081a65
      Reviewed-on: https://chromium-review.googlesource.com/c/1452097Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59329}
      bddc6aa5