X87: [runtime] Unify and simplify how frames are marked.

X87: [runtime] Unify and simplify how frames are marked.

  port 9dcd0857d64a117801bf91cb6caf7d6578809cb1 (r34571)

  original commit message:
  Before this CL, various code stubs used different techniques
  for marking their frames to enable stack-crawling and other
  access to data in the frame. All of them were based on a abuse
  of the "standard" frame representation, e.g. storing the a
  context pointer immediately below the frame's fp, and a
  function pointer after that. Although functional, this approach
  tends to make stubs and builtins do an awkward, unnecessary
  dance to appear like standard frames, even if they have
  nothing to do with JavaScript execution.

  This CL attempts to improve this by:

  * Ensuring that there are only two fundamentally different
    types of frames, a "standard" frame and a "typed" frame.
    Standard frames, as before, contain both a context and
    function pointer. Typed frames contain only a minimum
    of a smi marker in the position immediately below the fp
    where the context is in standard frames.
  * Only interpreted, full codegen, and optimized Crankshaft and
    TurboFan JavaScript frames use the "standard" format. All
    other frames use the type frame format with an explicit
    marker.
  * Typed frames can contain one or more values below the
    type marker. There is new magic macro machinery in
    frames.h that simplifies defining the offsets of these fields
    in typed frames.
  * A new flag in the CallDescriptor enables specifying whether
    a frame is a standard frame or a typed frame. Secondary
    register location spilling is now only enabled for standard
    frames.
  * A zillion places in the code have been updated to deal with
    the fact that most code stubs and internal frames use the
    typed frame format. This includes changes in the
    deoptimizer, debugger, and liveedit.
  * StandardFrameConstants::kMarkerOffset is deprecated,
    (CommonFrameConstants::kContextOrFrameTypeOffset
    and StandardFrameConstants::kFrameOffset are now used
    in its stead).

BUG=

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

[zhengxing.li, 2016-03-09 02:00:13]

zhengxing.li@intel.com changed reviewers:
+ chunyang.dai@intel.com, danno@chromium.org, weiliang.lin@intel.com

[zhengxing.li, 2016-03-09 02:00:14]

PTAL, thanks!

[Weiliang, 2016-03-10 02:21:34]

lgtm

[zhengxing.li, 2016-03-10 02:21:58]

The CQ bit was checked by zhengxing.li@intel.com

[commit-bot: I haz the power, 2016-03-10 02:22:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1774353002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1774353002/1

[commit-bot: I haz the power, 2016-03-10 02:39:41]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-10 02:40:07]

Description was changed from

==========
X87: [runtime] Unify and simplify how frames are marked.

  port 9dcd0857d64a117801bf91cb6caf7d6578809cb1 (r34571)

  original commit message:
  Before this CL, various code stubs used different techniques
  for marking their frames to enable stack-crawling and other
  access to data in the frame. All of them were based on a abuse
  of the "standard" frame representation, e.g. storing the a
  context pointer immediately below the frame's fp, and a
  function pointer after that. Although functional, this approach
  tends to make stubs and builtins do an awkward, unnecessary
  dance to appear like standard frames, even if they have
  nothing to do with JavaScript execution.

  This CL attempts to improve this by:

  * Ensuring that there are only two fundamentally different
    types of frames, a "standard" frame and a "typed" frame.
    Standard frames, as before, contain both a context and
    function pointer. Typed frames contain only a minimum
    of a smi marker in the position immediately below the fp
    where the context is in standard frames.
  * Only interpreted, full codegen, and optimized Crankshaft and
    TurboFan JavaScript frames use the "standard" format. All
    other frames use the type frame format with an explicit
    marker.
  * Typed frames can contain one or more values below the
    type marker. There is new magic macro machinery in
    frames.h that simplifies defining the offsets of these fields
    in typed frames.
  * A new flag in the CallDescriptor enables specifying whether
    a frame is a standard frame or a typed frame. Secondary
    register location spilling is now only enabled for standard
    frames.
  * A zillion places in the code have been updated to deal with
    the fact that most code stubs and internal frames use the
    typed frame format. This includes changes in the
    deoptimizer, debugger, and liveedit.
  * StandardFrameConstants::kMarkerOffset is deprecated,
    (CommonFrameConstants::kContextOrFrameTypeOffset
    and StandardFrameConstants::kFrameOffset are now used
    in its stead).

BUG=
==========

to

==========
X87: [runtime] Unify and simplify how frames are marked.

  port 9dcd0857d64a117801bf91cb6caf7d6578809cb1 (r34571)

  original commit message:
  Before this CL, various code stubs used different techniques
  for marking their frames to enable stack-crawling and other
  access to data in the frame. All of them were based on a abuse
  of the "standard" frame representation, e.g. storing the a
  context pointer immediately below the frame's fp, and a
  function pointer after that. Although functional, this approach
  tends to make stubs and builtins do an awkward, unnecessary
  dance to appear like standard frames, even if they have
  nothing to do with JavaScript execution.

  This CL attempts to improve this by:

  * Ensuring that there are only two fundamentally different
    types of frames, a "standard" frame and a "typed" frame.
    Standard frames, as before, contain both a context and
    function pointer. Typed frames contain only a minimum
    of a smi marker in the position immediately below the fp
    where the context is in standard frames.
  * Only interpreted, full codegen, and optimized Crankshaft and
    TurboFan JavaScript frames use the "standard" format. All
    other frames use the type frame format with an explicit
    marker.
  * Typed frames can contain one or more values below the
    type marker. There is new magic macro machinery in
    frames.h that simplifies defining the offsets of these fields
    in typed frames.
  * A new flag in the CallDescriptor enables specifying whether
    a frame is a standard frame or a typed frame. Secondary
    register location spilling is now only enabled for standard
    frames.
  * A zillion places in the code have been updated to deal with
    the fact that most code stubs and internal frames use the
    typed frame format. This includes changes in the
    deoptimizer, debugger, and liveedit.
  * StandardFrameConstants::kMarkerOffset is deprecated,
    (CommonFrameConstants::kContextOrFrameTypeOffset
    and StandardFrameConstants::kFrameOffset are now used
    in its stead).

BUG=

Committed: https://crrev.com/7a51f8c84329367c32d0c490ad2dab7c125da301
Cr-Commit-Position: refs/heads/master@{#34648}
==========

[commit-bot: I haz the power, 2016-03-10 02:40:09]

Patchset 1 (id:??) landed as
https://crrev.com/7a51f8c84329367c32d0c490ad2dab7c125da301
Cr-Commit-Position: refs/heads/master@{#34648}