1. 15 Feb, 2019 1 commit
  2. 07 Jan, 2019 1 commit
  3. 13 Nov, 2018 1 commit
  4. 06 Nov, 2018 1 commit
  5. 03 Aug, 2018 1 commit
  6. 31 Jul, 2018 1 commit
  7. 03 Jun, 2018 1 commit
  8. 23 Feb, 2018 1 commit
    • jgruber's avatar
      Remove unused runtime functions · 1ee80eba
      jgruber authored
      The list of runtime function use counts was generated with:
      
      $ grep -o '^ *F(\w*' src/runtime/runtime.h | sed 's/^ *F(//' | sort | while read f; do USE_COUNT=$(git grep "\(Runtime::k\|Runtime::kInline\|%\|%_\)$f" | wc -l); echo $USE_COUNT $f; done
      
      This reduces libv8.so size by 59K on an x64 release build.
      
      Bug: v8:7310
      Change-Id: Ib4d097e63ed065f41bf73e9529e4354575be5229
      Reviewed-on: https://chromium-review.googlesource.com/934272Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51526}
      1ee80eba
  9. 22 Feb, 2018 1 commit
  10. 29 Jan, 2018 1 commit
  11. 23 May, 2017 2 commits
    • machenbach's avatar
      Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3... · 3d40a47a
      machenbach authored
      Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3 id:40001 of https://codereview.chromium.org/2900703002/ )
      
      Reason for revert:
      Speculative revert for:
      https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8901
      
      Original issue's description:
      > [es2015] Precompute the descriptive string for symbols.
      >
      > Previously the String constructor and the Symbol.prototype.toString
      > methods had to compute the descriptive string for a Symbol on the fly,
      > which can produce a lot of garbage when this happens a lot, i.e. when
      > the String representation of a Symbol is used often. Now instead of
      > doing this on-demand we can just do it upfront when creating the Symbol.
      >
      > That way we also ensure that we won't throw an exception when accessing
      > the descriptive string of a Symbol, due to potential String length
      > overflow, but have the exception during Symbol creation upfront, which
      > is a lot less surprising behavior.
      >
      > BUG=v8:6278,v8:6344,v8:6350
      > TBR=mlippautz@chromium.org
      > R=ishell@chromium.org
      >
      > Review-Url: https://codereview.chromium.org/2900703002
      > Cr-Commit-Position: refs/heads/master@{#45479}
      > Committed: https://chromium.googlesource.com/v8/v8/+/e87573822e1c0c041c03f2b60599b0ab9256422f
      
      TBR=ishell@chromium.org,mlippautz@chromium.org,bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:6278,v8:6344,v8:6350
      
      Review-Url: https://codereview.chromium.org/2903533002
      Cr-Commit-Position: refs/heads/master@{#45483}
      3d40a47a
    • bmeurer's avatar
      [es2015] Precompute the descriptive string for symbols. · e8757382
      bmeurer authored
      Previously the String constructor and the Symbol.prototype.toString
      methods had to compute the descriptive string for a Symbol on the fly,
      which can produce a lot of garbage when this happens a lot, i.e. when
      the String representation of a Symbol is used often. Now instead of
      doing this on-demand we can just do it upfront when creating the Symbol.
      
      That way we also ensure that we won't throw an exception when accessing
      the descriptive string of a Symbol, due to potential String length
      overflow, but have the exception during Symbol creation upfront, which
      is a lot less surprising behavior.
      
      BUG=v8:6278,v8:6344,v8:6350
      TBR=mlippautz@chromium.org
      R=ishell@chromium.org
      
      Review-Url: https://codereview.chromium.org/2900703002
      Cr-Commit-Position: refs/heads/master@{#45479}
      e8757382
  12. 05 Jan, 2017 1 commit
  13. 06 Dec, 2016 1 commit
  14. 08 Jun, 2016 1 commit
  15. 06 Jun, 2016 1 commit
  16. 24 May, 2016 1 commit
  17. 29 Oct, 2015 1 commit
  18. 16 Sep, 2015 1 commit
    • bmeurer's avatar
      [builtins] Unify the String constructor. · a3d6f6cc
      bmeurer authored
      Implement the String constructor completely as native builtin,
      avoiding the need to do gymnastics in JavaScript builtin to
      properly detect the no argument case (which is different from
      the undefined argument case) and also allowing to just
      tailcall through to ToString or SymbolDescriptiveString for
      the common case. Also the JavaScript builtin was misleading
      since the case for construct call was unused, but could be
      triggered in a wrong way once we support tail calls from
      constructor functions.
      
      This refactoring allows us to properly implement subclassing
      for String builtins, once we have the correct initial_map on
      derived classes (it's merely a matter of using NewTarget
      instead of the target register now).
      
      This introduces a new %SymbolDescriptiveString runtime
      entry, which is also used by Symbol.toString() now.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1344893002
      
      Cr-Commit-Position: refs/heads/master@{#30759}
      a3d6f6cc
  19. 21 Aug, 2015 1 commit
    • yangguo's avatar
      Unify symbols sharing across native scripts and runtime. · eaba98d9
      yangguo authored
      We currently have several ways to share symbols that are used in
      both native scripts and the runtime. This change unifies this.
      We do not use the symbols registry since we don't need the
      registry any longer after bootstrapping, but the registry stays
      alive afterwards.
      
      R=mlippautz@chromium.org, rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1293493004
      
      Cr-Commit-Position: refs/heads/master@{#30280}
      eaba98d9
  20. 18 Aug, 2015 1 commit
  21. 31 Jul, 2015 1 commit
    • bmeurer's avatar
      [stubs] Unify (and optimize) implementation of ToObject. · 4fc6f547
      bmeurer authored
      This is the initial (big) step towards a more uniform implementation of
      the ToObject abstract operation (ES6 7.1.13), where we have a fallback
      implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
      to deal with the fast case (we should be able to do more cleanup on this
      in a followup CL).  For natives we expose the abstract operation via a
      %_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
      the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
      $toObject and %$toObject.  Now the whole implementation of the abstract
      operation is context independent, meaning we don't need any magic in the
      builtins object nor the native context.
      
      R=mvstanton@chromium.org,yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1266013006
      
      Cr-Commit-Position: refs/heads/master@{#29953}
      4fc6f547
  22. 16 Jun, 2015 1 commit
  23. 26 May, 2015 1 commit
    • erikcorry's avatar
      Move hash code from hidden string to a private symbol · eca5b5d7
      erikcorry authored
      * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
      * In the long run we should do all hidden properties this way and get rid of the
      hidden magic 0-length string with the zero hash code.  The advantages include
      less complexity and being able to do things from JS in a natural way.
      * Initially, the performance of weak set regressed, because it's a little harder
      to do the lookup in C++.  Instead of heroics in C++ to make things faster I
      moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
      * This also changes hash codes of Smis so that they are always Smis.
      
      Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
      
      In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
      
      In a similar vein we could give the magic zero hash code to the hash code
      symbol.  Then when we look up the hash code we would sometimes see the table
      with all the hidden properties.  This dual use of the field for either the hash
      code or the table with all hidden properties and the hash code is rather ugly,
      and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
      
      One worry is that the benchmark results above are more monomorphic than real
      world code, so may be overstating the performance benefits of moving to JS.  I
      think this is part of a general issue we have with handling polymorphic code in
      JS and any solutions there will benefit this solution, which boils down to
      regular property access. Any improvement there will lift all boats.
      
      R=adamk@chromium.org, verwaest@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1149863005
      
      Cr-Commit-Position: refs/heads/master@{#28622}
      eca5b5d7
  24. 20 May, 2015 1 commit
  25. 20 Oct, 2014 1 commit
  26. 30 Sep, 2014 1 commit