Skip to content

V
V8
Switch branch/tag
  1. 18 Oct, 2018 1 commit
  3. 17 Oct, 2018 2 commits
  5. 16 Oct, 2018 3 commits
  7. 15 Oct, 2018 3 commits
  9. 12 Oct, 2018 2 commits
    • Clemens Hammacher's avatar
      [base] Introduce MutexGuard as typedef for LockGuard<Mutex> · 75b56661
      Clemens Hammacher authored 
      LockGuard is mostly used with Mutex. Since both are defined outside the
internal namespace, we often have to write
{base::LockGuard<base::Mutex>}. This CL shortens this to
{base::MutexGuard} across the code base

R=mlippautz@chromium.org

Bug: v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I020d5933b73aafb98c4b72e3bb2dfd07c979ba73
Reviewed-on: https://chromium-review.googlesource.com/c/1278796Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56612}
      75b56661
    • Benedikt Meurer's avatar
      [async] Introduce the notion of a "current microtask". · 9f28c129
      Benedikt Meurer authored 
      Change the way we start collecting async stack traces by storing the
current microtask as a root instead of trying to make sense of the
last frame we see. This makes it possible to use the zero cost async
stack traces in Node.js as well (where the last JavaScript frame we
see is not the actual async function, but some frame related to the
main event loop usually).

In addition to the benefit that it now works with Node.js, we can also
extend the new machinery to look through (almost arbitrary) promise
chains. For example this code snippet

```js
(async function() {
  await Promise.resolve().then(() =>
    console.log(new Error().stack));
})();
```

can be made to also show the async function frame, even though at the
point where the stack trace is collected we don't have any async
function on the stack. But instead there's a PromiseReactionJobTask
as "current microtask", and we can dig into the chained promise to
see where the async execution is going to continue and eventually
find the await promise in the chain.

This also removes the removes the need to allocate `.generator_object`
specially during scope resolution.

Bug: v8:7522
Ref: nodejs/node#11865
Tbr: ulan@chromium.org
Design-Document: bit.ly/v8-zero-cost-async-stack-traces
Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203
Reviewed-on: https://chromium-review.googlesource.com/c/1277505
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56590}
      9f28c129
  11. 11 Oct, 2018 4 commits
  13. 10 Oct, 2018 7 commits
    • Michael Lippautz's avatar
      Revert "[heap] Run phantom handle callbacks on tear down" · d8d2533d
      Michael Lippautz authored 
      This reverts commit fa65063a.

Reason for revert:
This changes API contract with Blink as some state is destroyed before
actually tearing down the Isolate. Flushing the second round tasks
then tries to access various state that is already gone on the Blink
side. See bugs.

Bug: chromium:893944, chromium:893549, chromium:890631

Original change's description:
> [heap] Run phantom handle callbacks on tear down
>
> Pending phantom handle callbacks are not reliably executed if the heap
> shuts down. This can cause to memory leaks or other unwanted behaviour,
> like in wasm where the NativeModules (held in Managed objects
> implemented via phantom handles) unregister from the WasmEngine in the
> second-pass callback. This must be executed before tearing down the
> WasmEngine.
>
> This CL fixes this by running pending callback synchronously on heap
> tear down.
>
> R=ulan@chromium.org, mlippautz@chromium.org
>
> Bug: v8:8208
> Change-Id: I27b630c4d8f1fb12309040ea2179b64eed38710a
> Reviewed-on: https://chromium-review.googlesource.com/1249101
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56286}

TBR=ulan@chromium.org,mlippautz@chromium.org,clemensh@chromium.org

Bug: v8:8208
Change-Id: I4b403fd84473edb8895c3725ff3348574c54247b
Reviewed-on: https://chromium-review.googlesource.com/c/1274085
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56542}
      d8d2533d
    • Michael Lippautz's avatar
      [heap] Use non-nestable tasks for finalizing garbage collection · dfa56840
      Michael Lippautz authored 
      Pass on information about the embedder state using the fact that tasks
are run from top level

Bug: chromium:893944
Change-Id: I01441778770c5acc784540e496eec5c3fdb87796
Reviewed-on: https://chromium-review.googlesource.com/c/1273048
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56540}
      dfa56840
    • Hai Dang's avatar
      Add iterator protectors for JSMapIterator/JSSet/JSSetIterator. · 60d3ce72
      Hai Dang authored 
      The MapIterator protector protects the original iteration behaviors of
Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries().
It does not protect the original iteration behavior of
Map.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
  %MapIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
  holder is the %IteratorPrototype%. Note that this also invalidates the
  SetIterator protector (see below).

The SetIterator protector protects the original iteration behavior of
Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(),
and Set.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
  %SetIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
  holder is the %SetPrototype% OR %IteratorPrototype%. This means that
  setting Symbol.iterator on a MapIterator object can also invalidate the
  SetIterator protector, and vice versa, setting Symbol.iterator on a
  SetIterator object can also invalidate the MapIterator. This is an over-
  approximation for the sake of simplicity.

Bug: v8:7980
Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871
Reviewed-on: https://chromium-review.googlesource.com/c/1273102Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56530}
      60d3ce72
    • Marja Hölttä's avatar
      [js weak refs] Several fixes · ddbb12fa
      Marja Hölttä authored 
      1) As found by the GC fuzzer: missing HandleScopes.

2) The RecordSlot barrier was missing for NativeContext::AddDirtyJSWeakFactory.

3) Need Context::Scope to surround the cleanup function (if it results in an
error, we try to get native_context() from Isolate).

BUG=v8:8179,v8:8286

Change-Id: I2d995a76770658848e3c9629333bedbc2ef43b82
Reviewed-on: https://chromium-review.googlesource.com/c/1273051Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56529}
      ddbb12fa
    • Ross McIlroy's avatar
      [ObjectStats] Record SourcePositionTables correctly in gc object stats. · 8dd93a26
      Ross McIlroy authored 
      Change-Id: I405172d79e0cbb043ce369ded625940178344dde
Reviewed-on: https://chromium-review.googlesource.com/c/1273104Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56522}
      8dd93a26
    • Benedikt Meurer's avatar
      [esnext] Implement "Editorial: refactor PerformPromiseThen to allow no capability". · e24b95dc
      Benedikt Meurer authored 
      This implements the editorial change in https://github.com/tc39/ecma262/pull/1146
which removes the need to allocate the throwaway promise in await (the throwaway
promise was not exposed to user JavaScript anyways, but this spec change allows
us to rely on this behavior). Now we still need the throwaway promise for proper
before and after events with both DevTools (which might change) and PromiseHooks.
So if either DevTools or PromiseHooks is on, we call into %AwaitPromisesInit,
which then allocates the throwaway promise and does all the other debugger/hooks
related setup.

This gives around 7% improvement on the doxbee-async-es2017-native and around 1-2%
on the parallel-async-es2017-native benchmarks.

Bug: v8:7253, v8:8285
Ref: tc39/ecma262#1146
Tbr: ulan@chromium.org
Change-Id: I972ba0538ec8c00808e95b183603025c7e55a6d3
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1270798
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56506}
      e24b95dc
    • Igor Sheludko's avatar
      [cleanup] Split the mutable roots list into immovable and movable · 33ebe358
      Igor Sheludko authored 
      ... and remove Heap::RootCanBeWrittenAfterInitialization() and
Heap::RootCanBeTreatedAsConstant() in favour of RootsTable::IsImmortalImmovable().

Bug: v8:8238
Change-Id: I804d06136de9584b8c4940fd8ab9d18fb3ef7980
Reviewed-on: https://chromium-review.googlesource.com/c/1270837
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56500}
      33ebe358
  15. 09 Oct, 2018 8 commits
  17. 08 Oct, 2018 2 commits
  19. 05 Oct, 2018 2 commits
  21. 04 Oct, 2018 4 commits
  23. 02 Oct, 2018 2 commits