1. 17 Sep, 2018 1 commit
  2. 10 Jul, 2018 1 commit
  3. 23 Jun, 2018 1 commit
  4. 07 Jun, 2018 1 commit
  5. 24 May, 2018 1 commit
  6. 22 May, 2018 1 commit
  7. 17 May, 2018 1 commit
  8. 09 Apr, 2018 1 commit
  9. 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
  10. 08 Nov, 2017 1 commit
    • jgruber's avatar
      [factory] Simplify JSFunction creation · 72230246
      jgruber authored
      There's three common situations in which we need to create JSFunction
      objects.  1) from the compiler, 2) from tests, and 3) everything else
      (mostly during bootstrapping).
      
      This is an attempt to simplify case 3), which previously relied on
      several Factory::NewFunction overloads where it was not clear how the
      semantics of each overload differed.
      
      This CL removes all but one overload, and packs arguments into a new
      NewFunctionArgs helper class.
      
      It also removes the hacks around
      SFI::set_lazy_deserialization_builtin_id by explicitly passing
      builtin_id into Factory::NewSharedFunctionInfo.
      
      Drive-by-fix: Properly set is_constructor hint in
      SimpleCreateSharedFunctionInfo.
      
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ica94d95e72e443055db5e7ff9e8cdf4115201ef1
      Reviewed-on: https://chromium-review.googlesource.com/757094
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49224}
      72230246
  11. 09 Oct, 2017 1 commit
  12. 21 Sep, 2017 1 commit
  13. 22 Aug, 2017 2 commits
  14. 14 Aug, 2017 1 commit
  15. 15 Jun, 2017 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Move most WeakMap/WeakSet code from JS to C++ builtins" · 431abca0
      Adam Klein authored
      This reverts commit 8196e102.
      
      Reason for revert: Performance regression due to hashcode lookup.
      
      Original change's description:
      > [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins
      > 
      > They were already implemented mostly in C++ (only error/negative
      > cases were handled in script), so this is mostly just a cleanup.
      > Only the constructors remain in script after this CL.
      > 
      > Bug: v8:6354
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
      > Reviewed-on: https://chromium-review.googlesource.com/531670
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Commit-Queue: Adam Klein <adamk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45924}
      
      TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org
      Bug: v8:6354, chromium:733238
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0
      Reviewed-on: https://chromium-review.googlesource.com/537207Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45966}
      431abca0
  16. 13 Jun, 2017 1 commit
  17. 27 Apr, 2017 1 commit
  18. 07 Feb, 2017 1 commit
  19. 25 Jan, 2017 1 commit
  20. 07 Sep, 2016 1 commit
  21. 01 Sep, 2016 1 commit
  22. 20 May, 2016 1 commit
    • mlippautz's avatar
      [heap] Harden heap-related cctests · fdd9f6b9
      mlippautz authored
      - Move usable functions into proper heap-utils.h/.cc files and remove
        utils-inl.h file
      - Fix assumptions accross the board relying on certain behavior that is not
        invariant
      
      This is a requirement for modifying page size.
      
      BUG=chromium:581412
      LOG=N
      R=ulan@chromium.org
      
      Review-Url: https://codereview.chromium.org/1999753002
      Cr-Commit-Position: refs/heads/master@{#36410}
      fdd9f6b9
  23. 06 May, 2016 1 commit
  24. 15 Apr, 2016 2 commits
  25. 10 Feb, 2016 1 commit
    • mlippautz's avatar
      [heap] Move to page lookups for SemiSpace, NewSpace, and Heap containment methods · cfbd2561
      mlippautz authored
      Preparing the young generation for (real) non-contiguous backing memory, this
      change removes object masks that are used to compute containment in semi and new
      space. The masks are replaced by lookups for object tags and page headers, where
      possible.
      
      Details:
      - Use the fast checks (page header lookups) for containment in regular code.
      - Use the slow version that masks out the page start adress and iterates all
        pages of a space for debugging/verification.
      - The slow version works for off-heap/unmapped memory.
      - Encapsulate all checks for the old->new barrier in Heap::RecordWrite().
      
      BUG=chromium:581412
      LOG=N
      
      Review URL: https://codereview.chromium.org/1632913003
      
      Cr-Commit-Position: refs/heads/master@{#33857}
      cfbd2561
  26. 09 Dec, 2015 2 commits
  27. 07 Dec, 2015 1 commit
  28. 07 Oct, 2015 1 commit
  29. 06 Oct, 2015 1 commit
  30. 05 Oct, 2015 1 commit
  31. 10 Sep, 2015 1 commit
  32. 31 Aug, 2015 2 commits
    • hablich's avatar
      Revert of [heap] More flag cleanup. (patchset #8 id:140001 of... · 6eb83769
      hablich authored
      Revert of [heap] More flag cleanup. (patchset #8 id:140001 of https://codereview.chromium.org/1314863003/ )
      
      Reason for revert:
      Breaks http://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20-%202/builds/2372
      
      Original issue's description:
      > [heap] GC flag cleanup/restructuring.
      >
      > * GC's flags are now proper flags and not int.
      > * Callback flags are not threaded through but only set once like gc flags
      > * Callers of methods that trigger GCs need to pass a reason when not using
      >   the default parameters.
      >
      > Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
      > usually override the currently set flags upon finishing a GC cylce, but are able
      > to restore the previously set if desired. This is useful for explicitely
      > triggered scavenges or external requests that interrupt the current behaviour.
      >
      > BUG=
      >
      > Committed: https://crrev.com/f4f3b431b9ce0778d926acf03c0d36dae5c0cba4
      > Cr-Commit-Position: refs/heads/master@{#30457}
      
      TBR=hpayer@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1303393004
      
      Cr-Commit-Position: refs/heads/master@{#30463}
      6eb83769
    • mlippautz's avatar
      [heap] GC flag cleanup/restructuring. · f4f3b431
      mlippautz authored
      * GC's flags are now proper flags and not int.
      * Callback flags are not threaded through but only set once like gc flags
      * Callers of methods that trigger GCs need to pass a reason when not using
        the default parameters.
      
      Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
      usually override the currently set flags upon finishing a GC cylce, but are able
      to restore the previously set if desired. This is useful for explicitely
      triggered scavenges or external requests that interrupt the current behaviour.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1314863003
      
      Cr-Commit-Position: refs/heads/master@{#30457}
      f4f3b431
  33. 26 Aug, 2015 1 commit
  34. 01 Jun, 2015 1 commit
  35. 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