1. 03 Jul, 2017 12 commits
  2. 02 Jul, 2017 1 commit
  3. 30 Jun, 2017 27 commits
    • Josh Wolfe's avatar
      [intl] Implement Intl.NumberFormat.prototype.formatToParts · 6c1e67f8
      Josh Wolfe authored
      Includes unit tests for the post-processing step
      flatten_regions_to_parts().
      
      Bug: v8:5244
      TBR: bmeurer@chromium.org, rossberg@chromium.org
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Change-Id: I306dd1721cc00c5820b061f14c4b6866f8d938f6
      Reviewed-on: https://chromium-review.googlesource.com/529973
      Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
      Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46369}
      6c1e67f8
    • Aaron Gable's avatar
      Make Gerrit the default code review for V8 · c746dcf9
      Aaron Gable authored
      Bug: chromium:685318
      Change-Id: Ia603ad4a0a35bba5c5572cad32364ff3695b3a74
      Reviewed-on: https://chromium-review.googlesource.com/558191
      Commit-Queue: Aaron Gable <agable@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46368}
      c746dcf9
    • Mathias Bynens's avatar
      [elements] Rename IsHoleyElementsKind to IsHoleyOrDictionaryElementsKind · 2bee643d
      Mathias Bynens authored
      `IsHoleyElementsKind` doesn’t just check for holeyness — it checks for
      dictionary elements as well. Its name should reflect that.
      
      This patch renames `IsHoleyElementsKind` to
      `IsHoleyOrDictionaryElementsKind`, which makes it possible to rename
      `IsFastHoleyElementsKind` to `IsHoleyElementsKind` in a future patch.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Change-Id: Id799fe396442e9810426145359254d60990f8492
      Reviewed-on: https://chromium-review.googlesource.com/558344Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46367}
      2bee643d
    • Andreas Haas's avatar
      [wasm] Update spec tests · 951ab5c7
      Andreas Haas authored
      This CL updates the wasm spec tests. In addition it adds an
      assertNotEquals function to mjsunit.js, and it fixes the test harness
      to not call quit() because it causes a dead-lock in combination with
      async compilation.
      
      R=rossberg@chromium.org
      
      Change-Id: I50cf737993adb3e2bd27977efe7e20e304b89078
      Reviewed-on: https://chromium-review.googlesource.com/558077Reviewed-by: 's avatarAndreas Rossberg <rossberg@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46366}
      951ab5c7
    • Igor Sheludko's avatar
      [runtime] Fix broken definition of Array.prototype[@@iterator]. · 46a5d96b
      Igor Sheludko authored
      ...and cleanup definition of several builtins in %TypedArrayPrototype%.
      
      Bug: v8:6459, chromium:737877
      Change-Id: Ic5832847476bf5a544ae0b0df5df0ed4edd3e44c
      Reviewed-on: https://chromium-review.googlesource.com/558076Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46365}
      46a5d96b
    • Michael Lippautz's avatar
      [heap] Redo scavenging logic · ebc98f7f
      Michael Lippautz authored
      Replace the second level visitation with a much simpler logic that
      just separately dispatches the special cases. All other cases can
      use a dispatch that just evacuates an object based on size.
      
      This is similar to the logic used in the mark-compact collector. The
      goal is to align behaviors as much as possible, highlighting and 
      fixing performance issues in the different behaviors.
      
      This CL is mechanical as possible. A followup will clean
      up the naming scheme and dispatching.
      
      Bug: chromium:738368
      Change-Id: Ia5a426c5ebb25230000b127580c300c97cff8b1b
      Reviewed-on: https://chromium-review.googlesource.com/558060
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46364}
      ebc98f7f
    • Miran.Karic's avatar
      MIPS: Optimize add, sub and shift pair macro instructions. · 498964cd
      Miran.Karic authored
      The CL adds optimizations for AddPair, SubPair, ShlPair, ShrPair and
      SarPair macro instructions.
      
      BUG=
      
      Change-Id: I56460624adc0aa8ae135533ef4b99e0ed8360ccb
      Reviewed-on: https://chromium-review.googlesource.com/555513Reviewed-by: 's avatarIvica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
      Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
      Cr-Commit-Position: refs/heads/master@{#46363}
      498964cd
    • Michael Lippautz's avatar
      [gm] Detect goma usage from args.gn · 61d1ad23
      Michael Lippautz authored
      - Properly detect whether the args.gn config actually wants goma.
      - Read out cpu count dynamically.
      
      NOTRY=true
      
      Bug: 
      Change-Id: I7a687e873ef0b009ab6eaada384378d23e1dbb1e
      Reviewed-on: https://chromium-review.googlesource.com/558085
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46362}
      61d1ad23
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
    • Caitlin Potter's avatar
      [async-await] allocate HeapObjects for Await all at once. · b57366f2
      Caitlin Potter authored
      Allocates the Await success/failure closures, their context, and
      the two required JSPromise objects all at once in a single call,
      rather than performing multiple allocations throughout the function.
      
      Saves about 2kb of snapshot space on an x64.release build.
      
      Performance impact of this change has not been measured yet.
      
      BUG=v8:4483
      R=ishell@chromium.org, jgruber@chromium.org
      
      Change-Id: I8d911cb91f5d0e00544ad3ba608aa170f6b2f704
      Reviewed-on: https://chromium-review.googlesource.com/549999Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#46360}
      b57366f2
    • Dusan Simicic's avatar
      MIPS[64]: Implement MSA I5 instructions in simulator · 5f0d8288
      Dusan Simicic authored
      Add support for MSA I5 instructions in mips32 and mips64 simulators.
      
      Bug: 
      Change-Id: Ie1be499a1b3c686603348d895456b8f39d5c1002
      Reviewed-on: https://chromium-review.googlesource.com/552554Reviewed-by: 's avatarIvica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
      Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
      Cr-Commit-Position: refs/heads/master@{#46359}
      5f0d8288
    • jgruber's avatar
      [debug] Fix catch prediction for optimized frames · 582f38b3
      jgruber authored
      Catch prediction for optimized frames had two issues:
      
      Inlined frames were iterated from caller-to-callee (which could
      result in incorrect predictions if one frame predicted CAUGHT and
      another predicted PROMISE).
      
      When encountering a builtin frame, we'd unconditionally return its
      prediction (which is wrong if it predicted UNCAUGHT and another inlined
      frame predicted either CAUGHT or PROMISE).
      
      This CL fixes both issues and refactors the function to reduce nesting.
      
      BUG=v8:6536
      
      Change-Id: I764a4ec033e4476bd840134b5eacfe0e08b3c1a4
      Reviewed-on: https://chromium-review.googlesource.com/555519
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46358}
      582f38b3
    • jgruber's avatar
      [debug] Default to UNCAUGHT in catch prediction · 86f14765
      jgruber authored
      V8's catch prediction mechanism tries to predict whether a thrown
      exception will be caught, just by looking at the current call stack.
      
      At the time when catch prediction was first introduced, only a few
      builtins (mostly related to Promise and Generator) could end up being
      fed into the catch prediction mechanism. This is no longer the case now
      that builtins are used in new ways, e.g. Array.p.forEach's continuation
      builtins.
      
      This CL removes the need to explicitly mark all builtins visible to the
      StackFrameIterator as CAUGHT/UNCAUGHT/PROMISE, and instead defaults to
      treating unmarked builtins as UNCAUGHT.
      
      BUG=v8:6536
      
      Change-Id: Ibdc106a91b2b0ffb93099433077642cad02c71e2
      Reviewed-on: https://chromium-review.googlesource.com/555518
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46357}
      86f14765
    • Igor Sheludko's avatar
      [runtime] Remove Runtime::kFunctionSetInstanceClassName. · 3cb55265
      Igor Sheludko authored
      ... and set the instance class name in a bootstrapper instead.
      
      Change-Id: Ie8a9a0e7cdc22ca19616b4a0d09665e059cd4d3e
      Reviewed-on: https://chromium-review.googlesource.com/557864Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46356}
      3cb55265
    • Leszek Swirski's avatar
      [compiler] Remove frame state combine pushing · 0571adf1
      Leszek Swirski authored
      With FCG no longer able to deoptimize, we can remove the "push" version
      of output frame state combine, as deoptimisation to bytecode is always
      the PokeAt variant.
      
      Bug: v8:6409
      Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
      Reviewed-on: https://chromium-review.googlesource.com/557866
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46355}
      0571adf1
    • Jaime Bernardo's avatar
      [build] Set MSVS .obj folders in gyp for v8_base · 3bef2af6
      Jaime Bernardo authored
      Building on Windows with gyp fails depending on the result from
      sharding the src/v8.gyp:v8_base target. If two source files with the
      same name are in the same shard, their output object file path would
      conflict with one another. One example of this conflict is v8_base's
      runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
      is generated at build time, for which the files runtime.obj and
      Runtime.obj would be created, but MSVS overwrites one of them with
      the other.
      
      Dividing the .obj output path by the original source's extension
      prevents this overwrite.
      
      Refs: https://github.com/nodejs/node/pull/13959
      Bug: 
      Change-Id: I158e6178f2511297899ee50ea159f574916f903f
      Reviewed-on: https://chromium-review.googlesource.com/556599Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46354}
      3bef2af6
    • Andreas Haas's avatar
      Revert "[wasm] Run foreground compilation tasks as normal tasks" · 89154bf6
      Andreas Haas authored
      This reverts commit 1520a851.
      
      Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.
      
      Original change's description:
      > [wasm] Run foreground compilation tasks as normal tasks
      > 
      > This CL makes foreground compilation tasks normal (i.e. not cancelable)
      > again, because otherwise a deadlock can happen. I think the reason why
      > the foreground tasks were cancelable was to make sure that all tasks
      > either finish correctly or get canceled. However, since the isolate can
      > only shut down on the main thread, this means that the foreground task
      > should have already finished when the isolate shuts down, or it should
      > not have started at all. I reordered the deletion of the AsyncCompileJob
      > though to make sure that an AsyncCompileJob is removed from
      > CompilationManager before its promise is resolved.
      > 
      > Here is the deadlock: The JS code which is executed after a promise is
      > resolved is executed within the task which resolves the promise. In case
      > of async compilation this means that some JS code is executed within a
      > CompileTask. In JS, the shutdown of the isolate can be triggered. During
      > the shutdown of the isolate, the CancelableTaskManager waits for all
      > registered cancelable tasks to complete, including the CompileTask of
      > async compilation. This means that the CancelableTaskManager waits for
      > itself to finish, which is a deadlock.
      > 
      > R=​clemensh@chromium.org, mtrofin@chromium.org
      > 
      > Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
      > Reviewed-on: https://chromium-review.googlesource.com/554733
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46343}
      
      TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/558284Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46353}
      89154bf6
    • Andreas Haas's avatar
      Revert "[wasm] Update spec tests" · bfbabce1
      Andreas Haas authored
      This CL landed on top of another CL which I want to revert.
      
      This reverts commit 27b0d6a9.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Update spec tests
      > 
      > Update the spec tests in v8 to the most recent version.
      > 
      > R=​rossberg@chromium.org
      > CC=titzer@chromium.org
      > 
      > Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
      > Reviewed-on: https://chromium-review.googlesource.com/552155
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46346}
      
      TBR=mstarzinger@chromium.org,rossberg@chromium.org,ahaas@chromium.org
      
      Change-Id: I82e4a2887bcb867d3572b78c36a20adc05df0903
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/558040Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46352}
      bfbabce1
    • jgruber's avatar
      [coverage] Handle deleted coverage infos · 547c5d32
      jgruber authored
      It can happen that coverage infos for a function containing
      IncBlockCounter bytecodes can be deleted (e.g. by switching to
      best-effort coverage). Handle this case correctly in the IncBlockCounter
      runtime function.
      
      BUG=v8:6000
      
      Change-Id: I49b9f52822661150d55410d6b173b3929adf4af2
      Reviewed-on: https://chromium-review.googlesource.com/558039
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46351}
      547c5d32
    • Michael Achenbach's avatar
      Revert "[wasm] Allow the initialization of a single compilation unit" · fa4314da
      Michael Achenbach authored
      This reverts commit ca931562.
      
      Reason for revert: tsan:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007
      
      Original change's description:
      > [wasm] Allow the initialization of a single compilation unit
      > 
      > This CL adds a new function {InitializeCompilationUnit} to initialize
      > a single compilation unit and not just all compilation units at once.
      > This is necessary for streaming compilation eventually. This also
      > required some refactoring on how the working queue for compilation units
      > works. Previously the synchronization was done with an atomic counter,
      > now it is done with a lock. Note that the code to finish compilation
      > of a module still only works if the working queue gets only empty when
      > all work is done. I plan to change this in a different CL.
      > 
      > Since the code would not be tested without streaming compilation, I added
      > an experimental flag and a test to test the new code.
      > 
      > R=​clemensh@chromium.org, mtrofin@chromium.org
      > 
      > Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
      > Reviewed-on: https://chromium-review.googlesource.com/550096
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46348}
      
      TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/558224Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46350}
      fa4314da
    • Ulan Degenbaev's avatar
      Revert "[heap] Allow a minimum semi-space size of 512K." · f341bb0f
      Ulan Degenbaev authored
      This reverts commit 0d2ed6c3.
      
      The CL introduced perf regressions: crbug.com/735649.
      
      We are going to reland the CL in an isolated V8 roll to ensure
      that perf regressions are attributed correctly.
      
      Original commit message:
      > [heap] Allow a minimum semi-space size of 512K.
      > This CL also reduces the minimum semi-space size to 512K.
      > BUG=chromium:716032
      
      BUG=chromium:735649
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I1f1b08ca6853347c00070f000c309d839ff8a4bb
      Reviewed-on: https://chromium-review.googlesource.com/552541Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46349}
      f341bb0f
    • Andreas Haas's avatar
      [wasm] Allow the initialization of a single compilation unit · ca931562
      Andreas Haas authored
      This CL adds a new function {InitializeCompilationUnit} to initialize
      a single compilation unit and not just all compilation units at once.
      This is necessary for streaming compilation eventually. This also
      required some refactoring on how the working queue for compilation units
      works. Previously the synchronization was done with an atomic counter,
      now it is done with a lock. Note that the code to finish compilation
      of a module still only works if the working queue gets only empty when
      all work is done. I plan to change this in a different CL.
      
      Since the code would not be tested without streaming compilation, I added
      an experimental flag and a test to test the new code.
      
      R=clemensh@chromium.org, mtrofin@chromium.org
      
      Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
      Reviewed-on: https://chromium-review.googlesource.com/550096
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46348}
      ca931562
    • Marja Hölttä's avatar
      [parser] Skipping inner funcs: Associate data to SharedFunctionInfo, not Script. · 937b5011
      Marja Hölttä authored
      This way, each lazy function needs to handle only the data relevant to
      itself. This reduced data handling overheads.
      
      Other changes:
      
      1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
      function compilation is only done in the main thread.
      
      2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:
      
      - The data looks fundamentally different when we're producing it and when we're
        consuming it.
      
      - Cleanly separates the operations we can do in the "producing phase" and in the
        "consuming phase".
      
      Bug: v8:5516
      Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
      Reviewed-on: https://chromium-review.googlesource.com/528094
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46347}
      937b5011
    • Andreas Haas's avatar
      [wasm] Update spec tests · 27b0d6a9
      Andreas Haas authored
      Update the spec tests in v8 to the most recent version.
      
      R=rossberg@chromium.org
      CC=titzer@chromium.org
      
      Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
      Reviewed-on: https://chromium-review.googlesource.com/552155
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Rossberg <rossberg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46346}
      27b0d6a9
    • Ulan Degenbaev's avatar
      [heap] Avoid full GC for large heaps. · 52708b63
      Ulan Degenbaev authored
      BUG=chromium:738031
      
      Change-Id: I98d1015caadd7214a7076f7b39a4514bfd908061
      Reviewed-on: https://chromium-review.googlesource.com/555971Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46345}
      52708b63
    • Michael Lippautz's avatar
      [heap] Switch incremental marker to instance-based visitor · 6407a3c0
      Michael Lippautz authored
      Last marker to use the instance based visitors. Delete StaticMarkingVisitor.
      
      Bug: chromium:738368
      Change-Id: I7b5345805268aab277f2961c8598536dfa1a4eeb
      Reviewed-on: https://chromium-review.googlesource.com/556037Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46344}
      6407a3c0
    • Andreas Haas's avatar
      [wasm] Run foreground compilation tasks as normal tasks · 1520a851
      Andreas Haas authored
      This CL makes foreground compilation tasks normal (i.e. not cancelable)
      again, because otherwise a deadlock can happen. I think the reason why
      the foreground tasks were cancelable was to make sure that all tasks
      either finish correctly or get canceled. However, since the isolate can
      only shut down on the main thread, this means that the foreground task
      should have already finished when the isolate shuts down, or it should
      not have started at all. I reordered the deletion of the AsyncCompileJob
      though to make sure that an AsyncCompileJob is removed from
      CompilationManager before its promise is resolved.
      
      Here is the deadlock: The JS code which is executed after a promise is
      resolved is executed within the task which resolves the promise. In case
      of async compilation this means that some JS code is executed within a
      CompileTask. In JS, the shutdown of the isolate can be triggered. During
      the shutdown of the isolate, the CancelableTaskManager waits for all
      registered cancelable tasks to complete, including the CompileTask of
      async compilation. This means that the CancelableTaskManager waits for
      itself to finish, which is a deadlock.
      
      R=clemensh@chromium.org, mtrofin@chromium.org
      
      Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
      Reviewed-on: https://chromium-review.googlesource.com/554733
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46343}
      1520a851