1. 26 Aug, 2015 2 commits
  2. 18 Aug, 2015 1 commit
  3. 11 Aug, 2015 1 commit
    • bmeurer's avatar
      [runtime] Store constructor function index on primitive maps. · 6c743b2b
      bmeurer authored
      This way we can greatly simplify the different variants of ToObject in
      our codebase and make them more uniform and robust.  Adding a new
      primitive doesn't require finding and changing all those places again,
      but it is sufficient to setup the constructor function index when
      allocating the map.
      
      We use the inobject properties field of Map, which is invalid primitive
      maps anyway.
      
      R=jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/1276533003
      
      Cr-Commit-Position: refs/heads/master@{#30119}
      6c743b2b
  4. 23 Jun, 2015 1 commit
    • adamk's avatar
      Expose Map/Set methods through the API · df472240
      adamk authored
      Map: get, set, has, delete, clear
      Set: add, has, delete, clear
      
      All except clear are implemented as calls into collection.js.
      
      Note that some of these shadow methods of v8::Object. It's unclear
      how confusing that's going to be: on the one hand, it seems likely
      that most operations you would want to do on a Map or Set are these.
      On the other, generic code could get confused if it somehow gets
      ahold of a variable that happens to be C++-typed as a v8::Map or v8::Set.
      
      BUG=v8:3340
      LOG=y
      
      Review URL: https://codereview.chromium.org/1204623002
      
      Cr-Commit-Position: refs/heads/master@{#29237}
      df472240
  5. 26 May, 2015 2 commits
    • adamk's avatar
      Add basic API support for Map & Set · 395fa8ba
      adamk authored
      Only supports constructing new objects and returning size.
      Followup patch will need to add ability to retrieve and
      set contents in order to support structured clone.
      
      Also removes a bunch of outdated "experimental" markers from v8.h.
      
      BUG=v8:3340
      LOG=y
      
      Review URL: https://codereview.chromium.org/1157453002
      
      Cr-Commit-Position: refs/heads/master@{#28637}
      395fa8ba
    • 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
  6. 20 May, 2015 1 commit
  7. 11 May, 2015 1 commit
    • danno's avatar
      Add a MathFloor stub generated with TurboFan · abc35080
      danno authored
      This stub will be used as the basis of a Math.floor-specific CallIC to
      detect and track calls to floor that return -0.
      
      Along the way:
      - Create a TurboFanCodeStub super class from which the StringLength and
      MathRound TF stubs derive.
      - Fix the ugly hack that passes the first stub parameter as the "this"
      pointer in the the TF-compiled JS function.
      - Fix bugs in the ia32/x64 disassembler.
      
      Review URL: https://codereview.chromium.org/1137703002
      
      Cr-Commit-Position: refs/heads/master@{#28339}
      abc35080
  8. 17 Apr, 2015 1 commit
  9. 07 Apr, 2015 1 commit
    • adamk's avatar
      Reimplement Maps and Sets in JS · 909500aa
      adamk authored
      Previously, the only optimized code path for Maps and Sets was for String keys.
      This was achieved through an implementation of various complex operations
      in Hydrogen. This approach was neither scalable nor forward-compatible.
      
      This patch adds the necessary intrinsics to implement Maps and Sets almost entirely
      in JS. The added intrinsics are:
      
        %_FixedArrayGet
        %_FixedArraySet
        %_TheHole
        %_JSCollectionGetTable
        %_StringGetRawHashField
      
      With these additions, as well as a few changes to what's exposed as runtime functions,
      most of the C++ code backing Maps and Sets is gone (including both runtime code in
      objects.cc and Crankshaft in hydrogen.cc).
      
      Review URL: https://codereview.chromium.org/947683002
      
      Cr-Commit-Position: refs/heads/master@{#27605}
      909500aa
  10. 05 Feb, 2015 1 commit
    • yurys's avatar
      Add NativeWeakMap to v8.h · a5593679
      yurys authored
      A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
      
      BUG=chromium:437416
      LOG=Y
      
      Review URL: https://codereview.chromium.org/900123003
      
      Cr-Commit-Position: refs/heads/master@{#26451}
      a5593679
  11. 04 Feb, 2015 2 commits
  12. 03 Feb, 2015 2 commits
  13. 05 Dec, 2014 1 commit
  14. 17 Nov, 2014 1 commit
  15. 11 Nov, 2014 1 commit
  16. 04 Nov, 2014 1 commit
  17. 31 Oct, 2014 1 commit
    • ulan@chromium.org's avatar
      Clear old backing store of WeakCollection on updates. · de672226
      ulan@chromium.org authored
      Not clearing can lead to a crash under following conditions:
      1. Backing store of a weak map is allocated in large object space.
      2. The backing store is marked incrementaly via the weak map.
      3. The weak map is updated and gets a new backing store.
      4. The store buffer overflows and marks the chunk of the old backing store as
      "scan on scavenge."
      5. Mark-compact collection kills some elements of the weak map. Note that the
      old backing store survives because it was marked incrementally, but its dead
      elements are not cleared.
      6. Scavenger iterates over the old backing store, tries to move a dead object
      and crashes.
      
      BUG=v8:3631
      LOG=N
      TEST=cctest/test-heap/Regress3631
      R=jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/686783003
      
      Cr-Commit-Position: refs/heads/master@{#25032}
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25032 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      de672226
  18. 20 Oct, 2014 1 commit
  19. 29 Sep, 2014 1 commit