Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 04 Feb, 2016 1 commit
  5. 28 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Make Math.max and Math.min fast by default. · cb9b8010
      bmeurer authored 
      The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).

So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33582}
      cb9b8010
  7. 22 Jan, 2016 1 commit
    • 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
  9. 21 Jan, 2016 3 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
    • bmeurer's avatar
      [for-in] Sanitize for-in optimizations and fix bailout points. · f48bf12f
      bmeurer authored 
      The PrepareId bailout location was used incorrectly in Crankshaft and,
as it turns out, is not required anyway (once you do it right). Also
there was some premature optimization going on with the CheckEnumCache
(trying to load null from roots only once), plus we can be smarter about
the null/undefined check anyway.

The idea behind this changes is to prepare unification of the two
different ForInPrepare implementations that we now have, with the end
result being that we only use the new implementation that was recently
added for the interpreter.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33426}
      f48bf12f
  11. 20 Jan, 2016 1 commit
  13. 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
  15. 13 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number constructor similar to String constructor. · 322ffda3
      bmeurer authored 
      Also migrate the Number constructor to a native builtin, using the
same mechanism already used by the String constructor. Otherwise just
parsing and compiling the Number constructor to optimized code already
eats 2ms on desktop for no good reason, and the resulting optimized
code is not even close to awesome.

Drive-by-fix: Use correct context for the [[Construct]] case of the
String constructor as well, and share some code with it.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33265}
      322ffda3
  17. 30 Dec, 2015 1 commit
  19. 29 Dec, 2015 1 commit
  21. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored 
      According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}

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

Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored 
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )

Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind

Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}

TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629

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

Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  23. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored 
      According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  25. 23 Dec, 2015 1 commit
  27. 04 Dec, 2015 3 commits
  29. 03 Dec, 2015 2 commits
  31. 27 Nov, 2015 4 commits
  33. 26 Nov, 2015 1 commit
  35. 25 Nov, 2015 4 commits
  37. 24 Nov, 2015 1 commit
  39. 20 Nov, 2015 1 commit
  41. 19 Nov, 2015 2 commits
    • mstarzinger's avatar
      Simplify MacroAssembler::InvokePrologue a bit. · adec2638
      mstarzinger authored 
      This removes some dead code from the function invocation code when the
arguments adaptor trampoline is called. This seems to be leftover code
from when we used to support calling code objects directly.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32126}
      adec2638
    • mstarzinger's avatar
      [turbofan] Make new.target explicit in JSCallDescriptor. · 0227857d
      mstarzinger authored 
      This adds an explicit parameter to the call descriptor having kind
kJSCallFunction representing the new.target value. Note that for now
this parameter is not yet passed in and hence cannot be used yet. Also
contains some refactoring of how parameter index value are calculated,
establishing Linkage as the central point for such index computations.

This is a preparatory CL to allows us passing new.target in a register
instead of via a side-channel through the construct stub frame.

R=bmeurer@chromium.org
BUG=v8:4544
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32112}
      0227857d
  43. 04 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Implement the call protocol properly for direct calls. · 30aca03a
      bmeurer authored 
      The callees are expected to properly set the number of actual
arguments passed to the callee, which is now represented correctly
in the TurboFan graphs by a new Parameter right before the context
Parameter.  Currently this is only being used for outgoing calls.

Note that this requires disabling two of the TF code stub tests,
because of the JavaScript graphs are not automagically compatible
with abitrary (incoming) code stub interface descriptors.  If we
want to support JS code stubs at all, then we need to find a sane
way to feed in this information.

Drive-by-fix: Don't insert a direct call to a classConstructor.

R=mstarzinger@chromium.org
BUG=v8:4413, v8:4428
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31789}
      30aca03a
  45. 02 Oct, 2015 3 commits
    • danno's avatar
      Re-reland: Remove register index/code indirection · 5cf1c0bc
      danno authored 
      Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}

Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
Cr-Commit-Position: refs/heads/master@{#31075}

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

Cr-Commit-Position: refs/heads/master@{#31087}
      5cf1c0bc
    • danno's avatar
      Revert of Reland: Remove register index/code indirection (patchset #20... · 00e07b00
      danno authored 
      Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ )

Reason for revert:
Failures on MIPS

Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
>   so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
>   different platforms is now shared.
> * The list of allocatable registers on each platform is declared
>   as a list rather than implicitly via the register index <->
>   code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
>
> Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
> Cr-Commit-Position: refs/heads/master@{#31075}

TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#31083}
      00e07b00
    • danno's avatar
      Remove register index/code indirection · 7b7a8205
      danno authored 
      Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}

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

Cr-Commit-Position: refs/heads/master@{#31075}
      7b7a8205
  47. 30 Sep, 2015 1 commit
  49. 25 Sep, 2015 1 commit