-
danno authored
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). LOG=N Review URL: https://codereview.chromium.org/1696043002 Cr-Commit-Position: refs/heads/master@{#34571}
9dcd0857