Commit Graph

372 Commits

Author SHA1 Message Date
jkummerow
e83ac2342d [arm][arm64] Remove COHERENT_CACHE support
We have evidence (see r34896) that this avoids crashes.

BUG=chromium:524337

Review-Url: https://codereview.chromium.org/1995483002
Cr-Commit-Position: refs/heads/master@{#36317}
2016-05-18 11:08:52 +00:00
caitpotter88
d08c0304c5 [esnext] prototype runtime implementation for async functions
BUG=v8:4483
LOG=N
R=littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/1895603002
Cr-Commit-Position: refs/heads/master@{#36263}
2016-05-17 00:27:51 +00:00
caitpotter88
0d43421a22 [esnext] implement frontend changes for async/await proposal
BUG=v8:4483
LOG=Y
R=littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/1841543003
Cr-Commit-Position: refs/heads/master@{#36261}
2016-05-16 23:19:02 +00:00
mlippautz
95b8f3b0d3 Reland of [turbofan] Restore basic write barrier elimination. (patchset #1 id:1 of https://codereview.chromium.org/1943743003/ )
Reason for revert:
Jakob found the actual issue with the CL and is going to land the fix after relanding the WB elimination.

Original issue's description:
> Revert of [turbofan] Restore basic write barrier elimination. (patchset #2 id:20001 of https://codereview.chromium.org/1938993002/ )
>
> Reason for revert:
> Breaks WBs that should be there ;)
>
> https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305
>
> Will open repro bug asap.
>
> Original issue's description:
> > [turbofan] Restore basic write barrier elimination.
> >
> > Restore the basic write barrier elimination that we used to run as part
> > of the simplified lowering phase (in ChangeLowering actually) before, by
> > moving the write barrier computation to SimplifiedLowering where we can
> > still look at types and consider the heap/isolate, and just update the
> > WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> > lowering to a machine Load/Store.
> >
> > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> > R=mstarzinger@chromium.org
> > BUG=v8:4969,chromium:608636
> > LOG=n
> >
> > Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> > Cr-Commit-Position: refs/heads/master@{#35969}
>
> TBR=mstarzinger@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:4969,chromium:608636
>
> Committed: https://crrev.com/a782e93c617e728cded5ad878de11137a67891b7
> Cr-Commit-Position: refs/heads/master@{#35983}

TBR=mstarzinger@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:4969,chromium:608636

Review-Url: https://codereview.chromium.org/1943323002
Cr-Commit-Position: refs/heads/master@{#35984}
2016-05-03 13:56:30 +00:00
mlippautz
a782e93c61 Revert of [turbofan] Restore basic write barrier elimination. (patchset #2 id:20001 of https://codereview.chromium.org/1938993002/ )
Reason for revert:
Breaks WBs that should be there ;)

https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305

Will open repro bug asap.

Original issue's description:
> [turbofan] Restore basic write barrier elimination.
>
> Restore the basic write barrier elimination that we used to run as part
> of the simplified lowering phase (in ChangeLowering actually) before, by
> moving the write barrier computation to SimplifiedLowering where we can
> still look at types and consider the heap/isolate, and just update the
> WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> lowering to a machine Load/Store.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> R=mstarzinger@chromium.org
> BUG=v8:4969,chromium:608636
> LOG=n
>
> Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> Cr-Commit-Position: refs/heads/master@{#35969}

TBR=mstarzinger@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:4969,chromium:608636

Review-Url: https://codereview.chromium.org/1943743003
Cr-Commit-Position: refs/heads/master@{#35983}
2016-05-03 13:45:30 +00:00
bmeurer
7dcb6ad379 [turbofan] Restore basic write barrier elimination.
Restore the basic write barrier elimination that we used to run as part
of the simplified lowering phase (in ChangeLowering actually) before, by
moving the write barrier computation to SimplifiedLowering where we can
still look at types and consider the heap/isolate, and just update the
WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
lowering to a machine Load/Store.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969,chromium:608636
LOG=n

Review-Url: https://codereview.chromium.org/1938993002
Cr-Commit-Position: refs/heads/master@{#35969}
2016-05-03 09:43:46 +00:00
mtrofin
81a1530e6f [turbofan] CodeGenerator: Frame setup refactoring
Before frame elision, we finalized the frame shape when assembling the
prologue, which is also when we prepared the frame (saving sp, etc).

The frame finalization only needs to happen once, and happens to be
actually a set of idempotent operations. With frame elision, the logic for
frame finalization was happening every time we constructed the frame.
Albeit idempotent operations, the code would become hard to maintain.

This change separates frame shape finalization from frame
construction. When constructing the CodeGenerator, we finalize the
frame. Subsequent access is to a const Frame*.

Also renamed AssemblePrologue to AssembleConstructFrame, as
suggested in the frame elision CR.

Separating frame setup gave the opportunity to do away with
architecture-independent frame aligning (which is something just arm64
cares about), and also with stack pointer setup (also arm64). Both of
these happen now at frame finalization on arm64.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35642}
2016-04-20 05:41:06 +00:00
adamk
59546149c6 Remove all non-function-name uses of CONST_LEGACY
Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.

This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.

To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).

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

Cr-Commit-Position: refs/heads/master@{#35632}
2016-04-19 17:04:36 +00:00
zhengxing.li
1c5f0badbf X87: [turbofan] Need add V8_TARGET_ARCH_X87 in src/globals.h
The CL #35139 (https://codereview.chromium.org/1775323002) added V8_TARGET_ARCH_IA32 macro in
  src/globals.h.

  X87 is almost same as IA32, So It needs the V8_TARGET_ARCH_X87 macro in src/globals.h too.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35464}
2016-04-14 06:57:17 +00:00
verwaest
d2eb555ee1 Use a dictionary-mode code cache on the map rather than a dual system.
The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35291}
2016-04-06 10:06:30 +00:00
mtrofin
53d51c52f3 [turbofan] Frame elision for code stubs.
Removed Frame::needs_frame and the function-wide logic using it in
favor of FrameAccessState::has_frame, which can be set on a more
granular level, and driving it block by block.

BUG= v8:4533
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#35139}
2016-03-30 14:08:28 +00:00
oth
48d082af38 [interpreter] Add support for scalable operands.
This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.

Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.

The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.

LOG=N
BUG=v8:4747,v8:4280

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

Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:09:49 +00:00
yangguo
6e8958fff4 [serializer] ensure that immortal immovable roots are correctly deserialized.
Immortal immovable roots must be allocated on the first page of the space.
If serializing the root list exceeds the first page, immortal immovable root
objects might end up outside of the first page. That could cause missing
write barriers.

We now iterate the root list twice. The first time we only serialize immortal
immovable root objects. The second time we serialize the rest.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34859}
2016-03-17 13:16:25 +00:00
yangguo
f507bc1c72 [serializer] Add API to warm up startup snapshot with an additional script.
A startup snapshot is considered cold when it does not contain any
function code. We can now create a warm startup snapshot from a cold one
by running a warm-up script. Functions exercised by the warm-up script
are compiled and its code included in the warm startup snapshot. Side
effects caused by the warm-up script does not persist.

R=vogelheim@chromium.org
BUG=v8:4836
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#34849}
2016-03-17 10:34:16 +00:00
joransiu
daea0e7518 S390: Platform specific includes in common files
Add S390 platform specific \#includes across various common files.
Add S390 CPU features to enum.
Add S390 implementation to extract sp/fp/pc from signal context.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34674}
2016-03-10 14:03:51 +00:00
rossberg
4614c7caaf [strong] Remove all remainders of strong mode
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#34669}
2016-03-10 12:45:42 +00:00
mstarzinger
f53418b8ba [compiler] Move ClearExceptionFlag into Compiler.
The enum in question is (and should) no longer be used outside of the
compiler API and hence is being moved back into the Compiler class.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34526}
2016-03-07 10:17:36 +00:00
mstarzinger
00e9447ad3 Remove the global Strength enum class completely.
R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34398}
2016-03-01 16:06:04 +00:00
adamk
cc2ea25747 Don't reflect ES2015 Function name inference in Function.prototype.toString
Various syntactic forms now cause functions to have names where they
didn't before. Per the upcoming changes to the toString spec, only
a name that was literally part of a function's expression or declaration
is meant to be reflected in toString. This also happens to be the same
set of names that V8 currently outputs (without the --harmony-function-name
flag).

This required distinguishing anonymous FunctionExpressions from other sorts
of function definitions (like methods and getters/setters) in the AST, parser,
and at runtime.

The patch also takes the opportunity to remove one more argument (and enum)
from FunctionLiteral, as well as adding a special factory method for the
case of a FunctionLiteral representing toplevel or eval'd code.

BUG=v8:4760
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34132}
2016-02-19 02:51:10 +00:00
adamk
63efda35b3 Remove strong mode support from Scope and Variable
This frees up one bit in FunctionKind, which I plan to make slightly
more syntactic info about functions available in SharedFunctionInfo
(needed for ES2015 Function.name support).

BUG=v8:3956, v8:4760
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34125}
2016-02-18 17:20:13 +00:00
bmeurer
3ef573e9f1 [runtime] Optimize and unify rest parameters.
Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:

Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.

The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.

Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.

R=jarin@chromium.org, rmcilroy@chromium.org
TBR=rossberg@chromium.org
BUG=v8:2159
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33809}
2016-02-08 10:08:50 +00:00
yangguo
8a2d571734 [bootstrapper] extra natives must not use natives syntax.
R=bmeurer@chromium.org, domenic@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33770}
2016-02-05 12:33:55 +00:00
mlippautz
004ce08da6 Reland of "[heap] Parallel newspace evacuation, semispace copy, and compaction \o/"
This reverts commit 85ba94f28c.

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33552}
2016-01-27 13:24:59 +00:00
machenbach
85ba94f28c Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ (patchset #16 id:620001 of https://codereview.chromium.org/1577853007/ )
Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664

Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
>  - semispace copy: from space -> to space (within newspace)
>  - newspace evacuation: newspace -> oldspace
>  - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
>  - The hard cap on number of tasks has been lifted
>  - We cache store buffer entries locally before merging them back into the global
>    StoreBuffer in a finalization phase.
>  - We cache AllocationSite operations locally before merging them back into the
>    global pretenuring storage in a finalization phase.
>  - AllocationSite might be compacted while they would be needed for newspace
>    evacuation. To mitigate any problems we defer checking allocation sites for
>    newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}

TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

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

Cr-Commit-Position: refs/heads/master@{#33539}
2016-01-27 09:11:51 +00:00
mlippautz
8f0fd8c037 [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33523}
2016-01-26 15:08:31 +00:00
ishell
6131ab1edd [es6] Tail calls support.
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.

Tail calling can be enabled by --harmony-tailcalls flag.

BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33509}
2016-01-26 11:07:40 +00:00
neis
faf5e68169 Make generators non-constructable.
BUG=v8:4163,v8:4630
LOG=y

R=rossberg

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

Cr-Commit-Position: refs/heads/master@{#33360}
2016-01-18 13:11:06 +00:00
verwaest
8e28e851ee Install ConstructNonConstructable as construct stub for non-constructables.
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32223}
2015-11-24 17:17:00 +00:00
bmeurer
374b6ea210 [builtins] Sanitize the machinery around Construct calls.
There's no point in collecting feedback for super constructor calls,
because in all (interesting) cases we can gather (better) feedback from
other sources (i.e. via inlining or via using a LOAD_IC to get to the
[[Prototype]] of the target).  So CallConstructStub is now only used
for new Foo(...args) sites where we want to collect feedback in the
baseline compiler.  The optimizing compilers, Reflect.construct and
super constructor calls use the Construct builtin directly, which allows
us to remove some weird code from the CallConstructStub (and opens the
possibility for more code sharing with the CallICStub, maybe even going
for a ConstructICStub).

Also remove the 100% redundant HCallNew instruction, which is just a
wrapper for the Construct builtin anyway (indirectly via the
CallConstructStub).

Drive-by-fix: Drop unused has_function_cache bit on Code objects.

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

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

Cr-Commit-Position: refs/heads/master@{#32172}
2015-11-23 10:34:42 +00:00
bmeurer
7c3396d01c [builtins] Introduce specialized Call/CallFunction builtins.
Introduce receiver conversion mode specialization for the Call and
CallFunction builtins, so we can specialize the builtin functionality
(actually an optimization only) based on static information from the
callsite (this is basically a superset of the optimizations that were
available with the CallFunctionStub and CallICStub, except that these
optimizations are correct now).

This fixes a regression introduced by the removal of CallFunctionStub,
for programs that call a lot.

R=yangguo@chromium.org
BUG=chromium:552244
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31871}
2015-11-09 08:48:33 +00:00
verwaest
44c44521ae Remove CallFunctionStub, always call through the Call builtin (also from CallIC).
This fixes receiver conversion since the Call builtin does it correctly.

BUG=v8:4526
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31823}
2015-11-05 12:46:01 +00:00
cbruni
ab84025977 [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.

LOG=N
BUG=v8:4428

Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
Cr-Commit-Position: refs/heads/master@{#31786}

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

Cr-Commit-Position: refs/heads/master@{#31790}
2015-11-04 14:30:09 +00:00
cbruni
f1bb688e80 Revert of [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor. (patchset #20 id:370001 of https://codereview.chromium.org/1418623007/ )
Reason for revert:
failing build bot

Original issue's description:
> [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
>
> The current implementation of classes throws the TypeError at the wrong
> point, after activating a new context when directly calling a class
> constructor. According to the spec, the TypeError has to be thrown
> in the caller context.
>
> LOG=N
> BUG=v8:4428
>
> Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
> Cr-Commit-Position: refs/heads/master@{#31786}

TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4428

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

Cr-Commit-Position: refs/heads/master@{#31787}
2015-11-04 13:56:44 +00:00
cbruni
6a06bc0a77 [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.

LOG=N
BUG=v8:4428

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

Cr-Commit-Position: refs/heads/master@{#31786}
2015-11-04 13:24:09 +00:00
mvstanton
25d48ec37f Vector ICs: Allow for more IC kinds.
We have plans to create more ICs, and we are out of bits to represent the Kind
in the flags field of the code object. The InlineCacheState can lose a bit
because it no longer needs the DEFAULT state. That state existed as a way to
detect errors where code incorrectly looked at a vector IC stub's
InlineCacheState instead of correctly determining said state from a glance at
the vector. This really isn't a danger anymore.

So, with the horse trading, we could now represent up to 32 code kinds.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#31666}
2015-10-29 20:32:57 +00:00
mbrandy
2bd5914bc3 Fix external callback logging in profiler.
For platforms that use function descriptors (currently AIX and
PPC64BE), log an external callback's entrypoint address rather than
its function descriptor address.  This allows proper lookup in the
tick processor's symbol table.

R=jkummerow@chromium.org, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#31633}
2015-10-28 13:42:40 +00:00
adamk
24565b8598 Use Scope::function_kind_ to distinguish arrow function scopes
Previously, arrow function scopes had a separate ScopeType. However,
Scope::DeserializeScopeChain() erroneously deserialized ARROW_SCOPE
ScopeInfos as FUNCTION_SCOPE. This could lead to bugs such as the
attached one, where "super" was disallowed where it should have
been allowed.

This patch utilizes the Scope's FunctionKind to distinguish arrow
functions from others. Besides fixing the above bug, this also
simplifies code in various places that had to deal with two different
ScopeTypes both of which meant "function".

BUG=v8:4466
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31154}
2015-10-07 14:55:45 +00:00
ishell
90998947bc Distinction between FeedbackVectorICSlot and FeedbackVectorSlot eliminated.
This CL also allows to use arbitrary number of feedback vector elements for particular slot kind.

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

Cr-Commit-Position: refs/heads/master@{#31050}
2015-10-01 13:48:19 +00:00
mstarzinger
6a769ac1df [presubmit] Enable readability/namespace linter checking.
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31019}
2015-09-30 13:47:11 +00:00
bmeurer
93b2b2622b [es6] Introduce %ToInteger and %ToLength.
This adds ES6 compliant Object::ToInteger, Object::ToInt32,
Object::ToUint32 and Object::ToLength, and replaces the old
Execution wrappers of those abstract operations (which were
not using the correct ToPrimitive).

This also introduces proper %ToInteger and %ToLength runtime
entries, with a fast path %_ToInteger supported in fullcodegen
and Crankshaft (for now). Internal JavaScript code should use
TO_INTEGER and TO_LENGTH respectively.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
BUG=v8:4307
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#30993}
2015-09-29 07:41:13 +00:00
bmeurer
8fe3ac0701 [es6] Introduce spec compliant IsConstructor.
There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4413, v8:4430
LOG=n

Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
Cr-Commit-Position: refs/heads/master@{#30900}

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

Cr-Commit-Position: refs/heads/master@{#30902}
2015-09-24 06:50:11 +00:00
bmeurer
656ebdce8d Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )
Reason for revert:
Failed on Fuzzer and MIPS bot.

Original issue's description:
> [es6] Introduce spec compliant IsConstructor.
>
> There was already a bit on the Map named "function with prototype",
> which basically meant that the Map was a map for a JSFunction that could
> be used as a constructor. Now this CL generalizes that bit to
> IsConstructor, which says that whatever (Heap)Object you are looking at
> can be used as a constructor (i.e. the bit is also set for bound
> functions that can be used as constructors and proxies that have a
> [[Construct]] internal method).
>
> This way we have a single chokepoint for IsConstructor checking, which
> allows us to get rid of the various ways in which we tried to guess
> whether something could be used as a constructor or not.
>
> Drive-by-fix: Renamed IsConstructor on FunctionKind to
> IsClassConstructor to resolve the weird name clash, and the
> IsClassConstructor name also matches the spec.
>
> R=jarin@chromium.org, rossberg@chromium.org
> BUG=v8:4430
> LOG=n
>
> Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
> Cr-Commit-Position: refs/heads/master@{#30900}

TBR=jarin@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4430

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

Cr-Commit-Position: refs/heads/master@{#30901}
2015-09-24 05:27:00 +00:00
bmeurer
8de4d9351d [es6] Introduce spec compliant IsConstructor.
There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4430
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#30900}
2015-09-24 04:00:40 +00:00
bmeurer
1dfac69f1f [builtins] Add support for NewTarget to Execution::New.
Introduce new builtins Construct and ConstructFunction (in line
with the Call and CallFunction builtins that we already have) as
proper bottleneck for Construct and [[Construct]] on JSFunctions.
Use these builtins to support passing NewTarget from C++ to
JavaScript land.

Long-term we want the CallConstructStub to be used for
gathering feedback on entry to construction chain (i.e. the
initial new Foo), and use the Construct builtins to do the
actual work inside the construction chain (i.e. calling into
super and stuff).

MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.

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

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

Cr-Commit-Position: refs/heads/master@{#30857}
2015-09-22 04:27:28 +00:00
mstarzinger
093f7260e9 [presubmit] Fix runtime/indentation_namespace linter violations.
R=machenbach@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30514}
2015-09-01 15:20:09 +00:00
mstarzinger
8c70c20568 Remove code.h header and move ParameterCount class.
R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30291}
2015-08-21 10:25:21 +00:00
mstarzinger
58109a2c50 Remove several grab-bag includes from the v8.h header.
This is the first step of turning the v8.h file into a normal header
instead of an include-the-world header. The new rule is that no other
header files are allowed to include v8.h, which is enforced by DEPS.

Also the number of includes inside the v8.h file has been drastically
reduced. Basically the last missing piece is the inclusion of the big
objects-inl.h file.

This in turn makes many headers follow the IWYU principle.

R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30102}
2015-08-11 07:34:17 +00:00
bmeurer
6db78c8065 [turbofan] Drop V8_TURBOFAN_BACKEND and V8_TURBOFAN_TARGET defines.
TurboFan is now a requirement and supported by all backends, so we don't
need those macros (plus all the machinery on top) anymore.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30082}
2015-08-10 07:17:34 +00:00
mstarzinger
eabb514278 [heap] Remove unused support for heap iterator size function.
R=hpayer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#30071}
2015-08-07 13:46:46 +00:00
yangguo
4e036f3042 Debugger: refactor ScopeIterator, FrameInspector and DebugEvaluate.
This is a pure refactor and does not change functionality.

R=ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29995}
2015-08-04 12:10:13 +00:00