Skip to content

V
V8
Switch branch/tag
  1. 19 Sep, 2013 2 commits
  3. 18 Sep, 2013 2 commits
  5. 17 Sep, 2013 3 commits
  7. 12 Sep, 2013 3 commits
  9. 11 Sep, 2013 4 commits
  11. 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
  13. 08 Sep, 2013 1 commit
  15. 04 Sep, 2013 3 commits
  17. 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
  19. 02 Sep, 2013 1 commit
  21. 01 Sep, 2013 1 commit
  23. 30 Aug, 2013 1 commit
  25. 29 Aug, 2013 2 commits
  27. 28 Aug, 2013 7 commits
  29. 26 Aug, 2013 3 commits
  31. 23 Aug, 2013 4 commits
  33. 22 Aug, 2013 1 commit