Skip to content

V
V8
Switch branch/tag
  1. 14 Jan, 2015 2 commits
  3. 13 Jan, 2015 1 commit
  5. 10 Dec, 2014 2 commits
  7. 09 Dec, 2014 2 commits
  9. 05 Dec, 2014 1 commit
  11. 04 Dec, 2014 2 commits
  13. 21 Nov, 2014 1 commit
  15. 25 Sep, 2014 1 commit
  17. 19 Sep, 2014 1 commit
  19. 18 Sep, 2014 2 commits
  21. 23 Jun, 2014 1 commit
  23. 10 Jun, 2014 1 commit
  25. 05 Jun, 2014 1 commit
    • vogelheim@chromium.org's avatar
      Support external startup data in V8. · ba9f391b
      vogelheim@chromium.org authored 
      [Retry of crrev.com/293993021, which caused problems with 'ninja all' in Chromium. First patch set if a clean apply
of crrev.com/293993021. Subsequent sets are the actual fix
for that issue.]

If the embedder chooses, the 'natives' (library sources) and the
precompiled startup blob can be written to files during the build
process and handed over to V8 at startup. The main purpose would be
to reduce the size of the compiled binary for space constrained
platforms.

The build-time option is off by default. Nothing should change if
it's not enabled.

BUG=
R=jochen@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ba9f391b
  27. 04 Jun, 2014 1 commit
  29. 03 Jun, 2014 2 commits
  31. 29 Apr, 2014 1 commit
  33. 03 Sep, 2013 1 commit
  35. 12 Jun, 2013 1 commit
  37. 14 Sep, 2012 1 commit
    • erik.corry@gmail.com's avatar
      Refactoring of snapshots. This simplifies and improves · 5a8d1764
      erik.corry@gmail.com authored 
      the speed of deserializing code.  The current startup
time improvement for V8 is around 6%, but code deserialization
is speeded up disproportionately, and we will soon have more
code in the snapshot.
* Removed support for deserializing into large object space.
  The regular pages are 1Mbyte now and that is plenty.  This
  is a big simplification.
* Instead of reserving space for the snapshot we actually
  allocate it now.  This removes some special casing from
  the memory management and simplifies deserialization since
  we are just bumping a pointer rather than calling the
  normal allocation routines during deserialization.
* Record in the snapshot how much we need to boot up and
  allocate it instead of just assuming that allocations in
  a new VM will always be linear.
* In the snapshot we always address an object as a negative
  offset from the current allocation point.  We used to
  sometimes address from the start of the deserialized data,
  but this is less useful now that we have good support for
  roots and repetitions in the deserialization data.
* Code objects were previously deserialized (like other
  objects) by alternating raw data (deserialized with memcpy)
  and pointers (to external references, other objects, etc.).
  Now we deserialize code objects with a single memcpy,
  followed by a series of skips and pointers that partially
  overwrite the code we memcopied out of the snapshot.
  The skips are sometimes merged into the following
  instruction in the deserialization data to reduce dispatch
  time.
* Integers in the snapshot were stored in a variable length
  format that gives a compact representation for small positive
  integers.  This is still the case, but the new encoding can
  be decoded without branches or conditional instructions,
  which is faster on a modern CPU.
Review URL: https://chromiumcodereview.appspot.com/10918067

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      5a8d1764
  39. 19 Jun, 2012 1 commit
  41. 31 Jan, 2012 2 commits
  43. 30 Jan, 2012 2 commits
  45. 17 Jan, 2012 3 commits
  47. 23 May, 2011 1 commit
  49. 29 Apr, 2011 1 commit
  51. 18 Mar, 2011 3 commits
  53. 23 Mar, 2010 1 commit
  55. 16 Nov, 2009 1 commit