1. 21 Feb, 2022 1 commit
  2. 09 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [cleanup] Don't inherit from Tuple2 and Tuple3 · 24c23947
      Seth Brenith authored
      This change updates CachedTemplateObjectMap, BreakPointInfo, and
      BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3.
      It also removes Tuple3 because nothing else used Tuple3. By avoiding
      tuple types, we get various benefits that Torque can provide:
      - stricter debug verifier functions
      - accessors, cast functions, and printers are generated
      - BreakPoint and BreakPointInfo have different instance types, so you
        can tell them apart at runtime or in a debugger
      
      Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65668}
      24c23947
  3. 08 Jul, 2019 1 commit
  4. 23 May, 2019 2 commits
  5. 22 May, 2019 1 commit
  6. 20 May, 2019 1 commit
  7. 12 Mar, 2019 1 commit
  8. 25 Feb, 2019 1 commit
    • Ross McIlroy's avatar
      [Runtime] Ensure template objects are retained if bytecode is flushed. · ec9aef3d
      Ross McIlroy authored
      Template objects should be cached after they are first created and reused on
      subsiquent calls to tag functions. Currently these cached objects are stored
      on the feedback vector, which has appropriate lifetime, however with bytecode
      flushing the feedback vector could be cleared when the bytecode is flushed,
      causing the template object to be dropped.
      
      In order to retain the cached template objects in the face of bytecode flushing,
      this CL adds a weakmap for each native context that is (weakly) keyed by
      shared function info, and holds a linked list of cached template objects
      associated with that shared function info, indexed by feedback vector slot id.
      Misses will check this weakmap, and if no entry is found, a new template object
      is created and added into this weakmap alongside the feedback vector.
      
      BUG=v8:8799,v8:8799,v8:8395
      
      Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
      Reviewed-on: https://chromium-review.googlesource.com/c/1477746
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59818}
      ec9aef3d
  9. 25 Jan, 2019 1 commit
    • Mythri's avatar
      Defer inferring language mode as far as possible · 592aeefa
      Mythri authored
      Inferring the language mode involves iterating the stack to find the
      closure. This is an expensive operation and should be done only when
      required. This cl changes the implementation to infer the language
      mode only when we can't defer it any further. Currently, we infer the
      language mode when throwing an exception or when passing this
      information to PropertyCallbackArguments.
      
      This cl also changes the language mode parameter to SetProperty
      related methods to Maybe<ShouldThrow>. We only use the language mode to
      decide if we need to throw and using ShouldThrow instead of language
      mode simplifies the code by avoiding conversions from Maybe<ShouldThrow>
      to Maybe<LanguageMode> and vice-versa.
      
      Bug: v8:8580, chromium:923820, chromium:925289
      Change-Id: I72497497f62fe0d86fcecd57b06b3183b7531f7b
      Reviewed-on: https://chromium-review.googlesource.com/c/1425912
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59094}
      592aeefa
  10. 20 Jun, 2018 1 commit
  11. 09 Apr, 2018 1 commit
  12. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  13. 12 Feb, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  14. 25 Oct, 2017 1 commit
    • Jakob Kummerow's avatar
      [bigint] Fix abstract equality with junk strings · 98df94cd
      Jakob Kummerow authored
      Abstract equality comparison of a BigInt and a String converts the
      latter to BigInt. This conversion can fail; since we do not want to
      pass a context to the comparison function, we must signal such failure
      without throwing an exception.
      This CL uses the existing ShouldThrow enum to configure behavior of
      String-to-BigInt conversion, moving it out of Object into globals.h.
      
      Bug: v8:6791, v8:6979
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ibb98675079b8392cf03bbcbbbd5556108500a32d
      Reviewed-on: https://chromium-review.googlesource.com/734172
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48946}
      98df94cd
  15. 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