Skip to content

V
V8
Switch branch/tag
  1. 24 Oct, 2013 1 commit
    • yurys@chromium.org's avatar
      Record allocation stack traces · a083601e
      yurys@chromium.org authored 
      This is initial implementation of allocation profiler.

Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.

Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.

This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.

BUG=chromium:277984,v8:2949
R=hpayer@chromium.org, loislo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17365 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      a083601e
  3. 22 Oct, 2013 1 commit
  5. 21 Oct, 2013 2 commits
  7. 16 Oct, 2013 1 commit
  9. 15 Oct, 2013 2 commits
  11. 11 Oct, 2013 1 commit
  13. 04 Oct, 2013 2 commits
  15. 02 Oct, 2013 1 commit
  17. 30 Sep, 2013 1 commit
  19. 27 Sep, 2013 2 commits
  21. 26 Sep, 2013 2 commits
  23. 24 Sep, 2013 1 commit
  25. 23 Sep, 2013 1 commit
  27. 17 Sep, 2013 2 commits
  29. 12 Sep, 2013 2 commits
  31. 11 Sep, 2013 3 commits
  33. 10 Sep, 2013 1 commit
    • bmeurer@chromium.org's avatar
      Introduce a RandonNumberGenerator class. Refactor the random/private_random... · eb381b94
      bmeurer@chromium.org authored 
      Introduce a RandonNumberGenerator class. Refactor the random/private_random uses in Isolate/Context.

The RandomNumberGenerator is a pseudorandom number generator
with 48-bit state. It is properly seeded using either

(1) the --random-seed if specified, or
(2) the entropy_source function if configured, or
(3) /dev/urandom if available, or
(4) falls back to Time and TimeTicks based seeding.

Each Isolate now contains a RandomNumberGenerator, which replaces
the previous private_random_seed.

Every native context still has its own random_seed. But this random
seed is now properly initialized during bootstrapping,
instead of on-demand initialization. This will allow us to cleanup
and speedup the HRandom implementation quite a lot (this is delayed
for a followup CL)!

Also stop messing with the system rand()/random(), which should
not be done from a library anyway! We probably re-seeded the
libc rand()/random() after the application (i.e. Chrome) already
seeded it (with better entropy than what we used).

Another followup CL will replace the use of the per-isolate
random number generator for the address randomization and
thereby get rid of the Isolate::UncheckedCurrent() usage in
the platform code.

TEST=cctest/test-random-number-generator,cctest/test-random
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      eb381b94
  35. 04 Sep, 2013 1 commit
  37. 03 Sep, 2013 1 commit
    • bmeurer@chromium.org's avatar
      Import ConditionVariable class. · 281de965
      bmeurer@chromium.org authored 
      Condition variables are synchronization primitives that can be used
to block one or more threads while waiting for condition to become
true.

Right now we have only semaphores, mutexes and atomic operations for
synchronization, which results in quite complex solutions where an
implementation using condition variables and mutexes would be straight
forward.

There's also a performance benefit to condition variables and mutexes
vs semaphores, especially on Windows, where semaphores are kernel
objects, while mutexes are implemented as fast critical sections,
it CAN be beneficial performance-wise to use condition variables
instead of semaphores.

R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      281de965
  39. 02 Sep, 2013 1 commit
  41. 01 Sep, 2013 1 commit
  43. 30 Aug, 2013 1 commit
  45. 29 Aug, 2013 2 commits
  47. 28 Aug, 2013 7 commits