Skip to content

V
V8
Switch branch/tag
  1. 02 Jun, 2015 2 commits
  3. 01 Jun, 2015 6 commits
    • erikcorry's avatar
      Cosmetic changes to tests to make it easier to concatenate them. · 4f5337a2
      erikcorry authored 
      When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.

R=ulan@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1163803002

Cr-Commit-Position: refs/heads/master@{#28742}
      4f5337a2
    • chunyang.dai's avatar
      X87: [crankshaft] Record inlined shared function infos instead of closures. · aa31176a
      chunyang.dai authored 
      port 388e791d (r28672).

original commit message:

   The list of inlined functions is used in exactly two places - for live
    edit and to prevent code flushing for inlined functions - and those are
    fine with SharedFunctionInfo and don't require a closure.

    This is one additional step towards inlining based on SharedFunctionInfo
    instead of JSFunction.

BUG=

Review URL: https://codereview.chromium.org/1143003003

Cr-Commit-Position: refs/heads/master@{#28719}
      aa31176a
    • chunyang.dai's avatar
      X87: VectorICs: allocating slots for store ics in ast nodes. · f1cc4ed2
      chunyang.dai authored 
      port 5450fc07 (r18659)

original commit message:

    Also adapt code generation to pass the slot to the
    store/keyed-store ic. AST nodes ObjectLiteral, Assignment,
    ForEach, Call and CountOperation now include one or more
    feedback vector ic slot ids.

BUG=

Review URL: https://codereview.chromium.org/1155383003

Cr-Commit-Position: refs/heads/master@{#28718}
      f1cc4ed2
    • chunyang.dai's avatar
      X87: [es6] Support super.property in eval and arrow functions · b471651e
      chunyang.dai authored 
      port 44e98103 (r28644)

original commit message:

    When we enter a method that needs access to the [[HomeObject]]
    we allocate a local variable `.home_object` and assign it the
    value from the [[HomeObject]] private symbol. Something along
    the lines of:

      method() {
        var .home_object = %ThisFunction()[home_object_symbol];
        ...
      }

BUG=

Review URL: https://codereview.chromium.org/1158543004

Cr-Commit-Position: refs/heads/master@{#28717}
      b471651e
    • chunyang.dai's avatar
      X87: Move hash code from hidden string to a private symbol · 5211fa0c
      chunyang.dai authored 
      port eca5b5d7 (r28622).

original commit message:

   * 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%.

    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

    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.

BUG=

Review URL: https://codereview.chromium.org/1153963010

Cr-Commit-Position: refs/heads/master@{#28716}
      5211fa0c
    • chunyang.dai's avatar
      X87: Move work to omit unnecessary ObjectLiteral stores to the numbering pass. · 6b93438d
      chunyang.dai authored 
      port 32de6778 (r29615)

original commit message:

    The reason is that this information will be needed to compute the number of
    vector ic slots done at numbering time.

BUG=

Review URL: https://codereview.chromium.org/1165693002

Cr-Commit-Position: refs/heads/master@{#28715}
      6b93438d
  5. 26 May, 2015 1 commit
  7. 25 May, 2015 2 commits
  9. 21 May, 2015 2 commits
  11. 19 May, 2015 2 commits
  13. 14 May, 2015 1 commit
  15. 13 May, 2015 4 commits
  17. 12 May, 2015 1 commit
  19. 11 May, 2015 1 commit
  21. 08 May, 2015 2 commits
  23. 07 May, 2015 3 commits
  25. 06 May, 2015 2 commits
    • conradw's avatar
      [strong] Fix inlining issue · 97bee8e9
      conradw authored 
      The Hydrogen representation for binops was never changed to care about the
language mode. We thought this was ok, but it turns out we need to keep track
of it to make sure inlining doesn't mess with the "strongness" of binops.

Also added more rigorous inlining testing.

BUG=v8:3956
LOG=N

Review URL: https://codereview.chromium.org/1123043002

Cr-Commit-Position: refs/heads/master@{#28253}
      97bee8e9
    • chunyang.dai's avatar
      X87: Handle the case when derived constructor is [[Call]]ed with 0 args. · 5f047ff6
      chunyang.dai authored 
      port cf53fed9 (r28242).

original commit message:

    ArgumentsAdaptorStub for derived constructor (the one that needs
    new.target) works in this way:
     - If the constructor is invoked via the Construct stub, we know that
       actual arguments always include new.target. ``arguments`` object
       however should not include a new.target, therefore we remove it.
       We achieve this by decrementing the argument count.
     - If the constructor is invoked as a call, we do not care for a correct
       ``arguments`` array since the constructor will immediately throw on
       entrance.
    The bug is that the call could actually pass 0 actual arguments, but I
    decrement unconditionally :(. The fix is to detect this case and avoid
    decrementing. ``arguments`` is bogus, but it is ok as constructor
    throws.

    Long-term we should just remove mucking about with arguments for
    new.target and just get it from the stack.

BUG=

Review URL: https://codereview.chromium.org/1124063002

Cr-Commit-Position: refs/heads/master@{#28246}
      5f047ff6
  27. 05 May, 2015 1 commit
  29. 04 May, 2015 4 commits
  31. 30 Apr, 2015 4 commits
  33. 29 Apr, 2015 1 commit
  35. 28 Apr, 2015 1 commit