Skip to content

V
V8
Switch branch/tag
  1. 12 May, 2014 1 commit
  3. 09 May, 2014 2 commits
  5. 06 May, 2014 1 commit
  7. 05 May, 2014 1 commit
  9. 02 May, 2014 1 commit
  11. 29 Apr, 2014 1 commit
  13. 02 Apr, 2014 1 commit
  15. 21 Mar, 2014 1 commit
  17. 20 Mar, 2014 1 commit
  19. 11 Mar, 2014 1 commit
  21. 05 Mar, 2014 1 commit
  23. 12 Feb, 2014 1 commit
  25. 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
  27. 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
  29. 07 Jan, 2014 1 commit
    • jarin@chromium.org's avatar
      Fixed Lithium environment generation bug for captured objects (created · acf24331
      jarin@chromium.org authored 
      by escape analysis). Added several tests that expose the bug.

Summary:
LCodegen::AddToTranslation assumes that Lithium environments are
generated by depth-first traversal, but LChunkBuilder::CreateEnvironment
was generating them in breadth-first fashion. This fixes the
CreateEnvironment to traverse the captured objects depth-first.

Note:
It might be worth considering representing LEnvironment by a list
with the same order as the serialized translation representation
rather than having two lists with a subtle relationship between
them (and then serialize in a slightly different order again).

R=titzer@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18470 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      acf24331
  31. 20 Nov, 2013 1 commit
  33. 15 Nov, 2013 2 commits
  35. 14 Nov, 2013 2 commits
  37. 08 Nov, 2013 1 commit
  39. 21 Oct, 2013 1 commit
  41. 02 Oct, 2013 1 commit
  43. 16 Aug, 2013 1 commit
  45. 02 Aug, 2013 1 commit
    • loislo@chromium.org's avatar
      Extract hardcoded error strings into a single place and replace them with enum. · d2c443b7
      loislo@chromium.org authored 
      I'd like to propagate bailout reason to cpu profiler.
So I need to save it into heap object SharedFunctionInfo.
But:
1) all bailout reason strings spread across all the sources.
2) they are native strings and if I convert them into String then I may have a performance issue.
3) one byte is enough for 184 bailout reasons. Otherwise we need 8 bytes for the pointer.

Also I think it would be nice to have error strings collected in one place.
In that case we will get additional benefits:

It allows us to keep this set of messages under control.
It gives us a chance to internationalize them.
It slightly reduces the binary footprint.

From the other hand the developers have to add new strings into that enum.

BUG=
R=jkummerow@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16024 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d2c443b7
  47. 23 Jul, 2013 3 commits
  49. 05 Jul, 2013 1 commit
  51. 25 Jun, 2013 1 commit
  53. 03 Jun, 2013 1 commit
  55. 24 May, 2013 1 commit
  57. 02 May, 2013 1 commit
  59. 24 Apr, 2013 2 commits
  61. 22 Apr, 2013 1 commit
    • svenpanne@chromium.org's avatar
      Various improvements regarding the way we print code code comments. · 07a2a9cd
      svenpanne@chromium.org authored 
      * All Lithium instructions have an associated Hydrogen instruction now,
  simplifying things.

* Consistently print <Lithium instruction number,Hydrogen value id> prefixes.

* Do not print uninteresting Lithium instructions like empty gaps, jumps to the
  next instruction, etc.

* Removed special handling of HChange-like instructions, it is totally unclear
  why they had this special treatment. If we really want to print more
  information about Lithium instructions, we should do it in a totally way,
  anyway (e.g. by unifying things with the generation of hydrogen*.cfg files).

* Made deferred code and the jump table stand out a little bit more.

* Print info about special blocks like loop headers and OSR entries.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14370 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      07a2a9cd
  63. 18 Apr, 2013 1 commit
  65. 25 Feb, 2013 1 commit