1. 18 Jun, 2019 1 commit
  2. 12 Jun, 2019 1 commit
  3. 08 May, 2019 1 commit
  4. 03 May, 2019 2 commits
  5. 20 Sep, 2018 1 commit
  6. 06 Jun, 2018 1 commit
    • Andreas Haas's avatar
      [test] Make assertThrowsEquals use assertSame · 86a27207
      Andreas Haas authored
      The typical use of assertThrowsEquals is to check that a specific
      object is thrown. However, assertEquals only does a proper equality
      check for primitive types, not for complex types. Using assertSame
      does a reference equality check on objects, which is more what you
      would expect from assertThrowsEquals. For exception kind testing,
      assertThrowsEquals actually did not work correctly, assertThrows is
      better for that case.
      
      R=clemensh@chromium.org, mythria@chromium.org
      
      Change-Id: I24fb22e75fa33ebe90eb4bae40825119a054bba5
      Reviewed-on: https://chromium-review.googlesource.com/1087952Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53556}
      86a27207
  7. 30 Nov, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "[objects] No longer create short external strings." · fc50e2c4
      Michael Achenbach authored
      This reverts commit e42e7fc8.
      
      Reason for revert: Speculative revert for:
      https://crbug.com/v8/7149
      
      Original change's description:
      > [objects] No longer create short external strings.
      > 
      > This fixes String::MakeExternal() to bail out if the subject string
      > doesn't fit a regular ExternalString, instead of creating a short
      > external string. The observation here is that for short external strings
      > the overhead of having to have the StringResource plus going to the
      > runtime/C++ for each and every character access from JavaScript land
      > is probably bigger than the anticipated benefits.
      > 
      > If this turns out to be wrong and there's a real benefit, we should make
      > use of ThinStrings instead of having a separate way to represent
      > external strings.
      > 
      > Bug: v8:6621, v8:7109, v8:7145
      > Change-Id: I4b75da08b82a72027c782a69de9c8eaf3cca1d4d
      > Reviewed-on: https://chromium-review.googlesource.com/799750
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49735}
      
      TBR=yangguo@chromium.org,bmeurer@chromium.org
      
      Change-Id: I3f5cfa9ab5c99ddce1d61ede9ed9515cb3936cdd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6621, v8:7109, v8:7145, v8:7149
      Reviewed-on: https://chromium-review.googlesource.com/801675Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49770}
      fc50e2c4
    • Benedikt Meurer's avatar
      [objects] No longer create short external strings. · e42e7fc8
      Benedikt Meurer authored
      This fixes String::MakeExternal() to bail out if the subject string
      doesn't fit a regular ExternalString, instead of creating a short
      external string. The observation here is that for short external strings
      the overhead of having to have the StringResource plus going to the
      runtime/C++ for each and every character access from JavaScript land
      is probably bigger than the anticipated benefits.
      
      If this turns out to be wrong and there's a real benefit, we should make
      use of ThinStrings instead of having a separate way to represent
      external strings.
      
      Bug: v8:6621, v8:7109, v8:7145
      Change-Id: I4b75da08b82a72027c782a69de9c8eaf3cca1d4d
      Reviewed-on: https://chromium-review.googlesource.com/799750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49735}
      e42e7fc8
  8. 22 Nov, 2017 1 commit
  9. 15 Nov, 2017 1 commit
  10. 10 Aug, 2017 1 commit
  11. 31 Jul, 2017 1 commit
  12. 13 Jul, 2017 1 commit
  13. 06 Jul, 2017 1 commit
  14. 30 Jun, 2017 2 commits
    • 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
    • bmeurer's avatar
      [turbofan] Replace uninitialized JSConstruct nodes with SOFT deopt. · fd24deb0
      bmeurer authored
      Similar to JSCall, we can also replace uninitialized JSConstruct nodes
      with SOFT deopts to ensure that we don't generate unnecessary dead code.
      This for example shows up in the hot parts of the Node event emitter
      currently where the generic code for handling events with 4 or more
      parameters might not have been run, but we still generate most of the
      code because the new Array call in the beginning is not turned into
      a SOFT deopt immediately.
      
      Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
      Construct bytecodes a bit to reduce the amount of code duplication.
      
      BUG=v8:4551, v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2958253002
      Cr-Commit-Position: refs/heads/master@{#46339}
      fd24deb0
  15. 23 Jun, 2017 1 commit
  16. 08 Jun, 2017 1 commit
  17. 06 Jun, 2017 1 commit
  18. 27 Mar, 2017 1 commit
  19. 07 Mar, 2017 1 commit
  20. 25 Jan, 2017 1 commit
    • rmcilroy's avatar
      [complier] Enable parallel eager inner function compilation with compiler dispatcher. · 6d42c450
      rmcilroy authored
      Enable enqueueing of eager inner function compilation onto the compiler
      dispatcher. This enables these tasks to be performed in parallel to
      compilation of the outer functio (only for Ignition functions).
      We currently synchronize to ensure all inner function compilations
       are complete before executing the outer function - future work will
      allow outer function execution to happenin parallel to inner function
      compilation.
      
      BUG=v8:5203,v8:5215
      
      Review-Url: https://codereview.chromium.org/2611313002
      Cr-Commit-Position: refs/heads/master@{#42667}
      6d42c450
  21. 17 Jan, 2017 2 commits
  22. 03 Jan, 2017 1 commit
  23. 15 Dec, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Allocate registers used as call arguments on-demand. · ae741d04
      rmcilroy authored
      Allocate the registers used as arguments to a call on-demand after visiting the
      argument (or reciever). This means that the visited expression can use registers
      that would otherwise have been allocated for arguments which haven't been
      visited yet.
      
      The reason for doing this is to avoid keeping things live in registers
      unecessarily for chained function calls, which avoids a memory leak for
      functions which chain a large number of calls with large temporary arguments /
      recievers.
      
      BUG=chromium:672027
      
      Review-Url: https://codereview.chromium.org/2557173004
      Cr-Commit-Position: refs/heads/master@{#41714}
      ae741d04
  24. 14 Dec, 2016 1 commit
  25. 16 Nov, 2016 1 commit
    • jgruber's avatar
      [debug-wrapper] Further extend the debug wrapper · b06c4ce5
      jgruber authored
      This CL further extends the debug wrapper, migrates around 60 tests, and
      removes a few tests that use functionality we will not support anymore.
      
      In more detail:
      
      * Removed tests that use:
        * enable/disable individual breakpoints
        * invocationText()
        * the ScriptCollected event
        * showBreakPoints
        * evalFromScript (and similar)
        * mirror.constructedBy and mirror.referencedBy
        * event_data.promise()
      * Some frame.evaluate uses were adapted since due to differences between
        remote objects (inspector) and mirrors. For instance, exceptions are
        currently not recreated exactly, since the inspector protocol does not
        give us the stack and message separately. Other objects (such as
        'this' in debug-evaluate-receiver-before-super) need to be explicitly
        converted to a string before the test works correctly.
      * Ensure that inspector stores the script before sending ScriptParsed and
        ScriptFailedToParse events in order to be able to use the script from
        within those events.
      * Better remote object reconstruction (e.g. for undefined and arrays).
      * New functionality in wrapper:
        * debuggerFlags().breakPointsActive.setValue()
        * scripts()
        * execState.setVariableValue()
        * execState.scopeObject().value()
        * execState.scopeObject().property()
        * execState.frame().allScopes()
        * eventData.exception()
        * eventData.script()
        * setBreakPointsActive()
      
      BUG=v8:5530
      
      Review-Url: https://codereview.chromium.org/2497973002
      Cr-Commit-Position: refs/heads/master@{#41019}
      b06c4ce5
  26. 11 Nov, 2016 1 commit
    • jgruber's avatar
      [debug-wrapper] Conditional breaks, locals, evaluate, scopes · b32ee40d
      jgruber authored
      This CL adds support for:
      * conditional breaks in setBreakpoint,
      * locals in frame.local{Count,Name,Value},
      * evaluation on a frame in frame.evaluate,
      * and more detailed scope information in scopeObject.
      
      Uses of several functions that are not covered by the
      inspector protocol and are only used in tests have been removed.
      
      Local handling has been modified to also include arguments as locals.
      Inspector differs in this regard from our FrameDetails in that
      arguments are always shown as locals. Argument-related functions
      were removed.
      
      BUG=v8:5530
      
      Review-Url: https://codereview.chromium.org/2491543002
      Cr-Commit-Position: refs/heads/master@{#40917}
      b32ee40d
  27. 10 Nov, 2016 1 commit
  28. 08 Nov, 2016 2 commits
  29. 07 Nov, 2016 2 commits
  30. 28 Oct, 2016 1 commit
  31. 12 Aug, 2016 1 commit
  32. 28 Jul, 2016 3 commits