1. 24 May, 2019 1 commit
  2. 23 May, 2019 1 commit
  3. 04 Apr, 2019 1 commit
  4. 03 Jul, 2018 3 commits
    • Alexey Kozyatinskiy's avatar
      Reland "[debug] liveedit in native" · 5505c664
      Alexey Kozyatinskiy authored
      This is a reland of 3dfaf826
      
      Original change's description:
      > [debug] liveedit in native
      >
      > Liveedit step-by-step:
      > 1. calculate diff between old source and new source,
      > 2. map function literals from old source to new source,
      > 3. create new script for new_source,
      > 4. mark literals with changed code as changed, all others as unchanged,
      > 5. check that for changed literals there are no:
      >   - running generators in the heap,
      >   - non droppable frames (e.g. running generator) above them on stack.
      > 6. mark the bottom most frame with changed function as scheduled for
      >    restart if any.
      > 7. for unchanged functions:
      >   - deoptimize,
      >   - remove from cache,
      >   - update source positions,
      >   - move to new script,
      >   - reset feedback information and preparsed scope information if any,
      >   - replace any sfi in constant pool with changed one if any.
      > 8. for changed functions:
      >   - deoptimize
      >   - remove from cache,
      >   - reset feedback information,
      >   - update all links from js functions to old shared with new one.
      > 9. swap scripts.
      >
      > TBR=ulan@chromium.org
      >
      > Bug: v8:7862,v8:5713
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: I8f6f6156318cc82d6f36d7ebc1c9f7d5f3aa1461
      > Reviewed-on: https://chromium-review.googlesource.com/1105493
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54146}
      
      TBR=dgozman@chromium.org
      
      Bug: v8:7862, v8:5713
      Change-Id: I163ed2fd2ca3115ba0de74cb35a6fac9e40fdd94
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/1124879
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54187}
      5505c664
    • Yang Guo's avatar
      Revert "[debug] liveedit in native" · 22594d10
      Yang Guo authored
      This reverts commit 3dfaf826.
      
      Reason for revert: Failures - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20gcc%204.8/20394
      
      Original change's description:
      > [debug] liveedit in native
      > 
      > Liveedit step-by-step:
      > 1. calculate diff between old source and new source,
      > 2. map function literals from old source to new source,
      > 3. create new script for new_source,
      > 4. mark literals with changed code as changed, all others as unchanged,
      > 5. check that for changed literals there are no:
      >   - running generators in the heap,
      >   - non droppable frames (e.g. running generator) above them on stack.
      > 6. mark the bottom most frame with changed function as scheduled for
      >    restart if any.
      > 7. for unchanged functions:
      >   - deoptimize,
      >   - remove from cache,
      >   - update source positions,
      >   - move to new script,
      >   - reset feedback information and preparsed scope information if any,
      >   - replace any sfi in constant pool with changed one if any.
      > 8. for changed functions:
      >   - deoptimize
      >   - remove from cache,
      >   - reset feedback information,
      >   - update all links from js functions to old shared with new one.
      > 9. swap scripts.
      > 
      > TBR=ulan@chromium.org
      > 
      > Bug: v8:7862,v8:5713
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: I8f6f6156318cc82d6f36d7ebc1c9f7d5f3aa1461
      > Reviewed-on: https://chromium-review.googlesource.com/1105493
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54146}
      
      TBR=dgozman@chromium.org,ulan@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org
      
      Change-Id: I45df5b6f3abaf29e593c6ac11edefbd0177d0109
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7862, v8:5713
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/1124159Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54151}
      22594d10
    • Alexey Kozyatinskiy's avatar
      [debug] liveedit in native · 3dfaf826
      Alexey Kozyatinskiy authored
      Liveedit step-by-step:
      1. calculate diff between old source and new source,
      2. map function literals from old source to new source,
      3. create new script for new_source,
      4. mark literals with changed code as changed, all others as unchanged,
      5. check that for changed literals there are no:
        - running generators in the heap,
        - non droppable frames (e.g. running generator) above them on stack.
      6. mark the bottom most frame with changed function as scheduled for
         restart if any.
      7. for unchanged functions:
        - deoptimize,
        - remove from cache,
        - update source positions,
        - move to new script,
        - reset feedback information and preparsed scope information if any,
        - replace any sfi in constant pool with changed one if any.
      8. for changed functions:
        - deoptimize
        - remove from cache,
        - reset feedback information,
        - update all links from js functions to old shared with new one.
      9. swap scripts.
      
      TBR=ulan@chromium.org
      
      Bug: v8:7862,v8:5713
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I8f6f6156318cc82d6f36d7ebc1c9f7d5f3aa1461
      Reviewed-on: https://chromium-review.googlesource.com/1105493Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54146}
      3dfaf826
  5. 26 Jun, 2018 1 commit
  6. 22 Jun, 2018 1 commit
  7. 21 Jun, 2018 1 commit
  8. 20 Jun, 2018 2 commits
  9. 07 Jun, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[sfi] Remove SFI function literal id field" · b6888b63
      Leszek Swirski authored
      This reverts commit ceb9c812.
      
      Reason for revert: Tanks compile time
      
      Original change's description:
      > [sfi] Remove SFI function literal id field
      > 
      > SharedFunctionInfos store their original function literal's id. This is
      > also their index in the Script's SFI list.
      > 
      > Since the function literal id is only needed for lazy compilation and live
      > edit, we can calculate it on-the-fly by linear search in the Script SFI list,
      > and save a field on the SFI.
      > 
      > If this regresses compile performance, we could alternatively store the
      > function literal id on the preparsed scope data as future work.
      > 
      > Bug: chromium:818642
      > Change-Id: I5468cea0e115921f1c864d94e567d749a4349882
      > Reviewed-on: https://chromium-review.googlesource.com/1082480
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53523}
      
      TBR=hpayer@chromium.org,leszeks@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:818642
      Bug: chromium:850417
      Change-Id: If2fd21331b7062532c04004a51e705f7e9d0a151
      Reviewed-on: https://chromium-review.googlesource.com/1090494Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53573}
      b6888b63
  10. 05 Jun, 2018 1 commit
    • Leszek Swirski's avatar
      [sfi] Remove SFI function literal id field · ceb9c812
      Leszek Swirski authored
      SharedFunctionInfos store their original function literal's id. This is
      also their index in the Script's SFI list.
      
      Since the function literal id is only needed for lazy compilation and live
      edit, we can calculate it on-the-fly by linear search in the Script SFI list,
      and save a field on the SFI.
      
      If this regresses compile performance, we could alternatively store the
      function literal id on the preparsed scope data as future work.
      
      Bug: chromium:818642
      Change-Id: I5468cea0e115921f1c864d94e567d749a4349882
      Reviewed-on: https://chromium-review.googlesource.com/1082480
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53523}
      ceb9c812
  11. 01 Jun, 2018 1 commit
  12. 09 Apr, 2018 1 commit
  13. 02 Feb, 2018 1 commit
  14. 16 Oct, 2017 1 commit
  15. 13 Oct, 2017 1 commit
  16. 04 Aug, 2017 1 commit
  17. 16 Feb, 2017 1 commit
  18. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored
      Previously, when restarting a frame, we would rewrite all frames
      between the debugger activation and the frame to restart to squash
      them, and replace the return address with that of a builtin to
      leave that rewritten frame, and restart the function by calling it.
      
      We now simply remember the frame to drop to, and upon returning
      from the debugger, we check whether to drop the frame, load the
      new FP, and restart the function.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5587
      
      Review-Url: https://codereview.chromium.org/2636913002
      Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  19. 15 Dec, 2016 1 commit
  20. 14 Dec, 2016 1 commit
  21. 08 Dec, 2016 1 commit
  22. 06 Sep, 2016 1 commit
    • marja's avatar
      Include only stuff you need, part 8: Fix debug.h -> liveedit.h. · 51a3ffd9
      marja authored
      Rebuilding (after touching certain files) is crazy slow because
      includes are out of control.
      
      The (last remaining) offending include path is: ast.h <- liveedit.h <-
      debug.h <- src/x64/assembler-whatever-port-inl.h <-
      src/macro-assembler.h <- everything possible
      
      With this CL, the rebuild steps needed when touching ast-value-factory.h
      drops from 365 to 181.
      
      BUG=v8:5294
      TBR=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2316443002
      Cr-Commit-Position: refs/heads/master@{#39195}
      51a3ffd9
  23. 23 Aug, 2016 1 commit
  24. 09 Aug, 2016 1 commit
  25. 25 Jul, 2016 1 commit
    • nikolaos's avatar
      [parser] Refactor AstTraversalVisitor · ad6ea932
      nikolaos authored
      This patch parametrizes AstTraversalVisitor by the actual subclass,
      in a similar way as AstVisitor is parametrized.  This allows a
      subclass to, e.g., override the Visit method and still use the
      traversal mechanism.  It also allows the subclass to override the
      specific visiting methods, without them being virtual.
      
      This patch also removes AstExpressionVisitor, subsuming its
      functionality in AstTraversalVisitor.
      
      R=adamk@chromium.org, verwaest@chromium.org
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2169833002
      Cr-Commit-Position: refs/heads/master@{#37998}
      ad6ea932
  26. 08 Jun, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Improve contract for Compiler::CompileDebugCode. · 80b98da2
      mstarzinger authored
      This changes the contract for the aforementioned API function to be more
      permissive and allow callers to call it with less restrictions. The new
      contract is:
      
      a) For so far un-compiled functions, the compiler is free to choose the
         backend according to other decision criteria. Debug code can hence be
         provided by either Ignition or FullCodegen.
      b) For compiled functions, the compiler will provide debug code within
         the same tier as existing code. For Ignition the generated code will
         be equivalent to the old one. For FullCodegen the code will contain
         debug information and debug break slots.
      
      Concretely this fixes an issue where generator or async functions might
      have been compiled with an unexpected backend, due to the fact that the
      API method in question was always providing FullCodegen code.
      
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2044063002
      Cr-Commit-Position: refs/heads/master@{#36808}
      80b98da2
  27. 27 May, 2016 1 commit
  28. 18 May, 2016 1 commit
  29. 18 Apr, 2016 1 commit
  30. 08 Mar, 2016 2 commits
    • verwaest's avatar
      Add GetProperty/GetElement to JSReceiver and use it where possible · 77361020
      verwaest authored
      Also move GetProperty with string-name to JSReceiver
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1775973002
      
      Cr-Commit-Position: refs/heads/master@{#34596}
      77361020
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      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
  31. 05 Feb, 2016 1 commit
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      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}
      3f36e658
  32. 04 Feb, 2016 1 commit
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (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}
      bb31db3a
  33. 27 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      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}
      a7027851
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (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}
      d984b3b0
  34. 26 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      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}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      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}
      a5200f7e