Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

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

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

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

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

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

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

Adds support for generating deoptimization translations for interpreter
stack frames, and building interpreter frames for these translations
when a function deopts. Also adds builtins for
InterpreterNotifyDeoptimized which resume the function's continuation at
the correct point in the interpreter after deopt.

MIPS patch contributed by balazs.kilvady@igmtec.com

BUG=v8:4280
LOG=N
TEST=test-deoptimization.cc with --ignition and --turbo

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

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

We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).

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

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

R=mstarzinger@chromium.org
LOG=N
BUG=440500

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

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

It's expensive to walk all shared function infos during the gc atomic
pause. Instead, use WeakCells to implement this structure without
manual clearing.

Reland due to a bug when reusing entries in the optimized code map.

BUG=

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

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

Reason for revert:
Probably causes GC stress test failures.

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

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

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

It's expensive to walk all shared function infos during the gc atomic pause. Instead, use WeakCells to implement this structure without manual clearing.

BUG=

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

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

The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.

BUG=v8:1543
LOG=n

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

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

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

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

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

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

Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.

In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.

The following changes were specifically	needed:

* Frame	has been changed to explicitly manage three areas of the
  callee frame, the fixed header, the spill slot area, and the
  callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
  a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
  to support the new stack slot indexing scheme. Crankshaft, which
  doesn't support the new slot numbering in its register allocator,
  must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
  to support saving only the optimal set of used registers, which is
  only known after register allocation is finished and spill slots
  have been allocated.

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

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

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}

The calculation now takes into account the size of the arguments object
if it is present in the optimized frame.

(Yang, many thanks for the awesome repro!)

BUG=chromium:514362
LOG=N
R=yangguo@chromium.org

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

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

This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL).  For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject.  Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.

R=mvstanton@chromium.org,yangguo@chromium.org

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

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

The only right way to enable access checks is to install access check callbacks on an object template via v8::ObjectTemplate::SetAccessCheckCallbacks(). It does not make sense to enable access checks on an arbitrary object.

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

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

Also removed some unused classes.

BUG=

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

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

R=jarin@chromium.org

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

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

The remaining uses need some non-mechanical work:

  * non-standard-layout type, probably due to mixed access control

  * extended field designators

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

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

Also fixed the duplicated output of context deopt.

BUG=

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

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

Up until now we can only inline based on JSFunction, because of the way
the deoptimization works.  With this change we will be able to inline
based on the SharedFunctionInfo and materialize the JSFunction from a
literal or a stack slot when necessary.

R=jarin@chromium.org

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

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

Use the new TranslatedState and friends, which work at a higher level
than the TranslationIterator, which will make it easier to change the
deoptimization commands in subsequent CLs.

R=jarin@chromium.org

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

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

This unifies methods Deoptimizer::DoTranslateCommand, Deotpimizer::DoTranslateObject and the arguments object materializer.

To unify these, we have to separate reading of the input frame from writing to the output frame because the argument materializer does not write to output frames.

Instead, we now deoptimize in following stages:

1. Read out the input frame/registers, decode them using the translations from the deoptimizer and store them in the deoptimizer (Deoptimizer::translated_state_). This is done in TranslatedState::Init.

2. Write out into the output frame buffer all the values that do not require allocation. We also remember references to the values that require materialization. As before, this is done in Deoptimizer::DoCompute*Frame method, but instead calling to DoTranslateCommand, we use the translated frame to obtain the values and write them to the output frames.

3. The platform specific code then sets up the output frames and calls into the deoptimization notification. This has not been changed at all.

4. Once the stack is setup, we handlify all the references in the saved translated values (TranslatedState::Prepare).

5. Finally, we materialize all the values we remembered in step (1) and write them to their frames on the stack (using the TranslatedValue::GetValue method).

BUG=

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

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

Previously the %_DateField intrinsic would also check the object and
throw an exception if you happen to pass something that is not a valid
JSDate, which (a) violates our policy for instrinsics and (b) is hard to
optimize in TurboFan (even Crankshaft has a hard time, but there we will
never inline the relevant builtins, so it doesn't show up). The throwing
part is now a separate intrinsics %_ThrowIfNotADate that throws an
exception in full codegen and deoptimizes in Crankshaft, which means the
code for the current use cases is roughly the same (modulo some register
renamings/gap moves).

R=jkummerow@chromium.org

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

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

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

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

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

Repeat of https://codereview.chromium.org/1084763002/.

The 'final' RC has changed the version number, but the bug will not be
fixed until RTM.

LOG=N
R=jochen@chromium.org
BUG=chromium:440500

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

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

BUG=
R=titzer@chromium.org

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

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

BUG=chromium:476592
LOG=n

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

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

LOG=N
R=jochen@chromium.org
BUG=chromium:440500

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

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

I found some strange split in deopt entry points generator.
The code for table entry generator had two classes.
It is safe to join these classes together and drop virtual.

BUG=
LOG=n

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

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

the third part of the patch https://codereview.chromium.org/1012633002

this patch
1) moves DeoptInfo builder code to platform independent file lithium-codegen.cc
2) adds inlining_id property to HEnterInlined so we can use it on lithium level.

BUG=chromium:452067
LOG=n

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

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

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}

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}

Save Unknown position as zero in RelocInfo.
Remove copy constructor of SourcePosition because it is trivial.
Mechanical replace int raw_position with SourcePosition position.

BUG=452067
LOG=n

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

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

BUG=
R=mstarzinger@chromium.org

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

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

1) create beefy RelocInfo table when cpu profiler is active, so if a function
was optimized when profiler was active RelocInfo would get separate DeoptInfo
for the each deopt case.

2) push DeoptInfo from CodeEntry to ProfileNode.
When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.

Sample profile dump.
[Top down]:
    0  (root) 0 #1
    1     29 #2
    1      test 29 #3
    2        opt_function 29 #4
    2          opt_function 29 #5
                   deopted at 118 with reason 'not a heap number'
                   deopted at 137 with reason 'division by zero'

BUG=452067
LOG=n

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

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

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