There are no stale store buffer pointers anymore. The sweeper thread can not be in conflict with store buffer processing.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27107}

The prototype of a class constructor function is read only. When we set
computed property names we were ignoring this and we were overriding the
property.

Since the prototype is the only possible own read only property on the
constructor function object we special case this so we do not have to
check this for every property in the class literal.

BUG=v8:3945
LOG=N
R=mstarzinger@chromium.org, dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27106}

We can do that now since we have the invariant that the store buffer always has valid slots after marking.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27105}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27104}

This reduces the size of the StackHandler by one word. We no longer
need to keep track of the code object, as the stack walk finds it.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27103}

We can remove a few of them now (those which unconditionally bailout),
but this will be done in a separate CL to see any impact separately.

BUG=v8:3947
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27102}

Rolling v8/tools/clang to ed79fd57317ab9f09ce52a5e1c7424eebb80a73e

BUG=chromium:464657
LOG=n

TBR=machenbach@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27101}

Note that this patch is not really a *solution*, it is just enough to
make the undefined behavior unobservable. The real fix would be being
much more correct about sizes and signedness in our code base...

BUG=chromium:464657
LOG=n
R=dcarney@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27100}

BUG=chromium:465645
LOG=n
R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27099}

BUG=v8:3952
LOG=n
R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27098}

BUG=None
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#27097}

The bits in CompilerHints are accessed via FunctionKindBits, and on the other
hand, with accessors defined by BOOL_ACCESSORS(SharedFunctionInfo,
compiler_hints, is_accessor_function, kIsAccessorFunction) etc.

So the bit order in FunctionKind must match CompilerHints.

This is not causing problems (yet) because there's no accessor for these two
bits, but if somebody adds one, things will go wrong.

R=dslomov@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27096}

Revert of Fix old space check in IsSlotInBlackObject. (patchset #1 id:1 of https://codereview.chromium.org/993513009/)

Reason for revert:
Breaks arm.debug.

Original issue's description:
> Fix old space check in IsSlotInBlackObject.
>
> BUG=
>
> Committed: https://crrev.com/4f865389bcecdff6aa56512fab3a147507a95a51
> Cr-Commit-Position: refs/heads/master@{#27090}

TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27095}

We use slightly different schema for JumpTable on arm64 than for x64.

We do a branch (B) to the JumpTable from the code,
then a branch (B) to the end of jump table code
and then branch to the deoptimizer code with putting
the return address into lr register (Call which is actually Blr).

As a result the 'from' address in Deoptimizer always points to
the end of JumpTable code and we can get nothing from this information.

0) I moved save_doubles and needs_frame code out of for_loop.

1) I replaced B commands with Bl so we put different return addresses
to lr register for the different jump table entries and replaced
the final Call with Br which do not touch lr register.

Also I removed the last_entry check so we will always do the Bl
even for the last entry because we need the right address in lr.
I don't think that this will affect the performance because it
just one more branch for entire deopt mechanics.

BUG=chromium:452067
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27094}

R=svenpanne@chromium.org
BUG=chromium:465564
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27093}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27092}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27091}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27090}

R=jarin@chromium.org
BUG=chromium:465663
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27089}

R=mstarzinger@chromium.org
BUG=chromium:462775
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#27088}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27087}

Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.

Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.

Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.

BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27086}

Context specialization enables inlining (at least currently it is the
only enabler for inlining), but inlining enables more possibilities for
context specialization. So we really need to run them together.

This is especially important with the "module based builtins" that we're
working towards.

BUG=v8:3952
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27085}

since the old style weakness is slated for removal, we might as well reuse the name to limit confusion.  additionally I simplified the callback type to a enum to either get internal field values or not

this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused.

R=jochen@chromium.org, erikcorry@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27084}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27083}

BUG=chromium:464657
LOG=n
TBR=jochen@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27082}

BUG=chromium:464657
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27081}

Note that this is done only for consistency at this point in time.
The change should probably have been in
https://codereview.chromium.org/984963002/ already.

BUG=v8:3947
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27080}

R=hpayer@chromium.org
LOG=n
BUG=none

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

Cr-Commit-Position: refs/heads/master@{#27079}

Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27078}

R=dslomov@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27077}

The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.

We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.

The test was reworked so it tests identical functions against different reasons.

BUG=chromium:452067
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27076}

Methods can refer to the class name.

BUG=v8:3927
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27075}

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27074}

After establishing the invariant that the store buffer always has valid slots after marking, the store buffer integrity check is not needed anymore.

BUG=454157
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#27073}

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27072}

This slightly hacky change provides lazy deopt points for to-number conversions in binops: When we deopt from a to-number conversion, we create a frame state with the already-converted value(s) so that we do not repeat the side effect of the conversion.

Embenchen numbers are below. It is not quite clear what happened to fasta - the hot code looks nearly identical.

Current: EmbenchenBox2d(RunTime): 12746 ms.
d8-master: EmbenchenBox2d(RunTime): 13861 ms.
----------- bullet.js
Current: EmbenchenBullet(RunTime): 17680 ms.
d8-master: EmbenchenBullet(RunTime): 19170 ms.
----------- copy.js
Current: EmbenchenCopy(RunTime): 4939 ms.
d8-master: EmbenchenCopy(RunTime): 4943 ms.
----------- corrections.js
Current: EmbenchenCorrections(RunTime): 6639 ms.
d8-master: EmbenchenCorrections(RunTime): 6728 ms.
----------- fannkuch.js
Current: EmbenchenFannkuch(RunTime): 4630 ms.
d8-master: EmbenchenFannkuch(RunTime): 4872 ms.
----------- fasta.js
Current: EmbenchenFasta(RunTime): 10209 ms.
d8-master: EmbenchenFasta(RunTime): 9673 ms.
----------- lua_binarytrees.js
Current: EmbenchenLuaBinaryTrees(RunTime): 12936 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 15529 ms.
----------- memops.js
Current: EmbenchenMemOps(RunTime): 7357 ms.
d8-master: EmbenchenMemOps(RunTime): 7340 ms.
----------- primes.js
Current: EmbenchenPrimes(RunTime): 7530 ms.
d8-master: EmbenchenPrimes(RunTime): 7457 ms.
----------- skinning.js
Current: EmbenchenSkinning(RunTime): 15832 ms.
d8-master: EmbenchenSkinning(RunTime): 15630 ms.
----------- zlib.js
Current: EmbenchenZLib(RunTime): 11176 ms.
d8-master: EmbenchenZLib(RunTime): 11324 ms.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27071}

This makes sure only the %_DeoptimizeNow intrinsic is inlined, and
not the %DeoptimizeNow one. It hence re-establishes the invariant
that JSIntrinsicLowering only deals with inline intrinsics.

R=jarin@chromium.org
TEST=mjsunit/compiler/eager-deopt-simple

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

Cr-Commit-Position: refs/heads/master@{#27070}

The JSInliner used to load the context from the JSFunction node at
runtime, which introduced a HeapConstant (because we had to materialize
the JSFunction after context specialization) and a LoadField operation,
independent whether the inlinee actually uses the context. This is
rather cumbersome currently, and therefore this is now changed to just
embed the context constant instead. Once we do inlining based on
SharedFunctionInfo rather than JSFunction, we should reconsider this
decision and come up with a proper heuristic.

BUG=v8:3952
LOG=n
R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27069}

The store buffer can contain stale store buffer entries, i.e., slot in dead objects pointing to new space objects. These slots are treaded as live slots which cause problems with non-pointer fields and makes concurrent sweeping complicated. Removing these pointers from the store buffer before it is used makes life easier.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27068}