1. 16 Dec, 2016 1 commit
  2. 04 Nov, 2016 1 commit
  3. 03 Nov, 2016 2 commits
  4. 08 Sep, 2016 1 commit
  5. 05 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Move tracing runtime instrumentation closer to the original version. · e5ba156d
      fmeawad authored
      After we landed the tracing runtime call stats, which gave
      us a lot of V8 insight in tracing, we noticed that there is
      some arising issues and discrepancies.
      
      Issues include:
      Missing trace events, that happened due to
      transforming those trace events into runtime calls
      
      Discrepancies include:
      Missing categories in Runtime call stats like GC,
      because we are not handling the Scoped runtime calls
      properly in the tracing version.
      
      To reduce/eliminate those issue, we are taking a small
      step back. We are unifying the RuntimeStats code and
      using the original one. That would allow us to use all
      the original probes but emit trace events from them.
      We are also putting back the trace-events in their place.
      
      The output from both system should be intact (Except of
      the addition of the missing trace-events).
      
      Also as a byproduct, we are reducing the number of context
      scopes by half since we are using the same scope as
      runtime call stats.
      
      As a follow up to this CL, we will address the non-scoped
      Runtime Call Stats (mainly in GC).
      BUG=642373
      
      Review-Url: https://codereview.chromium.org/2296243002
      Cr-Commit-Position: refs/heads/master@{#39180}
      e5ba156d
  6. 10 Aug, 2016 1 commit
  7. 08 Aug, 2016 1 commit
  8. 05 Aug, 2016 1 commit
  9. 03 Aug, 2016 4 commits
  10. 19 Jul, 2016 1 commit
  11. 14 Jul, 2016 1 commit
  12. 11 May, 2016 1 commit
  13. 06 Apr, 2016 1 commit
    • cbruni's avatar
      [runtime] reduce runtime function and builtins overhead · ceb14f8c
      cbruni authored
      All the counters, trace events and runtime call stats roughly create a 30%
      overhead when calling into the runtime. This CL factors out the counters into
      separate non-inlined functions. This way we can reduce the overhead to a
      minimum and still have some useful stats without a compile-time flag.
      
      BUG=chromium:596055
      LOG=n
      
      Review URL: https://codereview.chromium.org/1868513002
      
      Cr-Commit-Position: refs/heads/master@{#35308}
      ceb14f8c
  14. 11 Mar, 2016 1 commit
  15. 10 Mar, 2016 1 commit
  16. 09 Mar, 2016 1 commit
  17. 08 Mar, 2016 1 commit
  18. 23 Feb, 2016 1 commit
    • cbruni's avatar
      [counters] Making runtime counters reentrant. · 5e468666
      cbruni authored
      So far counters did not work when they were reentrant and thus would lead to
      wrong bookkeeping of the counter stack. Using a separate stack-allocated linked
      list to track the timer stack solves this issue. This is a temporary workaround
      with the limitations of the counter system in mind. Eventually we will move to
      the trace-based system for these kind of statistics.
      
      BUG=v8:4770
      LOG=n
      
      Review URL: https://codereview.chromium.org/1695733002
      
      Cr-Commit-Position: refs/heads/master@{#34208}
      5e468666
  19. 11 Feb, 2016 4 commits
  20. 09 Feb, 2016 3 commits
  21. 08 Feb, 2016 2 commits
  22. 22 Jan, 2016 2 commits
    • jarin's avatar
      Runtime call counters and timers. · 747bd6f2
      jarin authored
      In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.
      
      In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)
      
      chrome --js-flags="--runtime-call-stats --allow-natives-syntax"
      
      To get the stats in the console, just run
      
      console.log(%GetAndResetRuntimeCallStats());
      
      To output stats every second:
      
      setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)
      
      Review URL: https://codereview.chromium.org/1615943002
      
      Cr-Commit-Position: refs/heads/master@{#33462}
      747bd6f2
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · ed2be747
      ishell authored
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      
      Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      
      This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      
      BUG=v8:4267
      LOG=Y
      
      Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
      Cr-Commit-Position: refs/heads/master@{#33438}
      
      Review URL: https://codereview.chromium.org/1587073003
      
      Cr-Commit-Position: refs/heads/master@{#33461}
      ed2be747
  23. 21 Jan, 2016 2 commits
    • machenbach's avatar
      Revert of Array length reduction should throw in strict mode if it can't... · 575e90c1
      machenbach authored
      Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ )
      
      Reason for revert:
      [Sheriff] Breaks layout tests. Please fix upstream.
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
      
      Original issue's description:
      > Array length reduction should throw in strict mode if it can't delete an element.
      >
      > When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      >
      > Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      >
      > This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      >
      > BUG=v8:4267
      > LOG=Y
      >
      > Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
      > Cr-Commit-Position: refs/heads/master@{#33438}
      
      TBR=verwaest@chromium.org,ishell@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4267
      
      Review URL: https://codereview.chromium.org/1611313003
      
      Cr-Commit-Position: refs/heads/master@{#33444}
      575e90c1
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · 1d3e837f
      ishell authored
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
      
      Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
      
      This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
      
      BUG=v8:4267
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1587073003
      
      Cr-Commit-Position: refs/heads/master@{#33438}
      1d3e837f
  24. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  25. 11 Dec, 2015 1 commit
  26. 10 Dec, 2015 1 commit
  27. 08 Oct, 2015 2 commits