1. 30 Jan, 2014 1 commit
    • jarin@chromium.org's avatar
      The current · 99ce5a24
      jarin@chromium.org authored
      version is passing all the existing test + a bunch of new tests
      (packaged in the change list, too).
      
      The patch extends the SlotRef object to describe captured and duplicated
      objects. Since the SlotRefs are not independent of each other anymore,
      there is a new SlotRefValueBuilder class that stores the SlotRefs and
      later materializes the objects from the SlotRefs.
      
      Note that unlike the previous implementation of SlotRefs, we now build
      the SlotRef entries for the entire frame, not just the particular
      function.  This is because duplicate objects might refer to previous
      captured objects (that might live inside other inlined function's part
      of the frame).
      
      We also need to store the materialized objects between other potential
      invocations of the same arguments object so that we materialize each
      captured object at most once.  The materialized objects of frames live
      in the new MaterielizedObjectStore object (contained in Isolate),
      indexed by the frame's FP address.  Each argument materialization (and
      deoptimization) tries to lookup its captured objects in the store before
      building new ones.  Deoptimization also removes the materialized objects
      from the store. We also schedule a lazy deopt to be sure that we always
      get rid of the materialized objects and that the optmized function
      adopts the materialized objects (instead of happily computing with its
      captured representations).
      
      Concerns:
      
      - Is the FP address the right key for a frame? (Note that deoptimizer's
      representation of frame is different from the argument object
      materializer's one - it is not easy to find common ground.)
      
      - Performance is suboptimal in several places, but a quick local run of
      benchmarks does not seem to show a perf hit. Examples of possible
      improvements: smarter generation of SlotRefs (build other functions'
      SlotRefs only for captured objects and only if necessary), smarter
      lookup of stored materialized objects.
      
      - Ideally, we would like to share the code for argument materialization
      with deoptimizer's materializer.  However, the supporting data structures
      (mainly the frame descriptor) are quite different in each case, so it
      looks more like a separate project.
      
      Thanks for any feedback.
      
      R=danno@chromium.org, mstarzinger@chromium.org
      LOG=N
      BUG=
      
      Committed: https://code.google.com/p/v8/source/detail?r=18918
      
      Review URL: https://codereview.chromium.org/103243005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      99ce5a24
  2. 29 Jan, 2014 2 commits
    • jarin@chromium.org's avatar
      Revert "Captured arguments object materialization" · ec51f26b
      jarin@chromium.org authored
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/130803009
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18923 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ec51f26b
    • jarin@chromium.org's avatar
      This is a preview of the captured arguments object materialization, · 868ad01e
      jarin@chromium.org authored
      mostly to make sure that it is going in the right direction. The current
      version is passing all the existing test + a bunch of new tests
      (packaged in the change list, too).
      
      The patch extends the SlotRef object to describe captured and duplicated
      objects. Since the SlotRefs are not independent of each other anymore,
      there is a new SlotRefValueBuilder class that stores the SlotRefs and
      later materializes the objects from the SlotRefs.
      
      Note that unlike the previous implementation of SlotRefs, we now build
      the SlotRef entries for the entire frame, not just the particular
      function.  This is because duplicate objects might refer to previous
      captured objects (that might live inside other inlined function's part
      of the frame).
      
      We also need to store the materialized objects between other potential
      invocations of the same arguments object so that we materialize each
      captured object at most once.  The materialized objects of frames live
      in the new MaterielizedObjectStore object (contained in Isolate),
      indexed by the frame's FP address.  Each argument materialization (and
      deoptimization) tries to lookup its captured objects in the store before
      building new ones.  Deoptimization also removes the materialized objects
      from the store. We also schedule a lazy deopt to be sure that we always
      get rid of the materialized objects and that the optmized function
      adopts the materialized objects (instead of happily computing with its
      captured representations).
      
      Concerns:
      
      - Is there a simpler/more correct way to store the already-materialized
      objects? (At the moment there is a custom root reference to JSArray
      containing frames' FixedArrays with their captured objects.)
      
      - Is the FP address the right key for a frame? (Note that deoptimizer's
      representation of frame is different from the argument object
      materializer's one - it is not easy to find common ground.)
      
      - Performance is suboptimal in several places, but a quick local run of
      benchmarks does not seem to show a perf hit. Examples of possible
      improvements: smarter generation of SlotRefs (build other functions'
      SlotRefs only for captured objects and only if necessary), smarter
      lookup of stored materialized objects.
      
      - Ideally, we would like to share the code for argument materialization
      with deoptimizer's materializer.  However, the supporting data structures
      (mainly the frame descriptor) are quite different in each case, so it
      looks more like a separate project.
      
      Thanks for any feedback.
      
      R=mstarzinger@chromium.org, danno@chromium.org
      LOG=N
      BUG=
      
      Review URL: https://codereview.chromium.org/103243005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      868ad01e