1. 09 Jan, 2019 1 commit
  2. 08 Jan, 2019 1 commit
  3. 26 Dec, 2018 1 commit
  4. 20 Dec, 2018 1 commit
  5. 04 Dec, 2018 1 commit
  6. 26 Nov, 2018 1 commit
  7. 25 Nov, 2018 1 commit
  8. 24 Nov, 2018 1 commit
  9. 23 Nov, 2018 2 commits
  10. 22 Nov, 2018 1 commit
  11. 13 Nov, 2018 1 commit
  12. 05 Nov, 2018 1 commit
  13. 29 Oct, 2018 1 commit
  14. 24 Oct, 2018 1 commit
  15. 18 Oct, 2018 1 commit
  16. 10 Oct, 2018 1 commit
    • 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
  17. 09 Oct, 2018 1 commit
  18. 29 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Unify handling of await closure contexts. · 9e99297e
      Benedikt Meurer authored
      Change the way that the (internal) await closures store the link to the
      generator object by introducing a dedicated AwaitContext, which stores
      the generator object into the extension slot (instead of misusing a
      regular FunctionContext here). Also unify the allocation+initialization
      of these contexts in the await-related builtins (both for async functions
      and generators).
      
      The rationale behind this is that for (zero-cost) async stack traces, we
      will need to dig into these contexts and we can do better checking with
      a dedicated instance type there. As an additional benefit, we save one
      word per await context, since we just use (the otherwise unused) extension
      slot to remember the generator object. As yet another benefit we will
      never accidentally use any of these contexts in the regular scope chain
      lookups, meaning we can also catch bugs there. And last but not least
      the objects printing machinery understands these contexts now and can
      even print the generator object for AwaitContexts for short printing,
      which is really valuable for debugging.
      
      Tbr: ulan@chromium.org
      Bug: v8:7253, v8:7522, v8:8015
      Change-Id: I86955f5701e694e8a10b91ebe5f52705aa90968d
      Reviewed-on: https://chromium-review.googlesource.com/1249491Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56301}
      9e99297e
  19. 24 Aug, 2018 1 commit
  20. 30 Jul, 2018 1 commit
  21. 17 Jul, 2018 1 commit
  22. 05 Jul, 2018 1 commit
  23. 19 Jun, 2018 1 commit
  24. 15 Jun, 2018 1 commit
  25. 12 Jun, 2018 1 commit
  26. 03 May, 2018 1 commit
  27. 23 Mar, 2018 3 commits
  28. 18 Dec, 2017 1 commit
  29. 13 Oct, 2017 1 commit
  30. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  31. 24 Jul, 2017 2 commits
  32. 20 Jul, 2017 1 commit
  33. 13 Jul, 2017 1 commit
  34. 10 Jul, 2017 1 commit
  35. 29 Jun, 2017 1 commit
  36. 29 May, 2017 1 commit