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
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
Drop the previous Mutex and ScopedLock classes from platform files.
Add new Mutex, RecursiveMutex and LockGuard classes, which are
designed after their C++11 counterparts, so that at some point
we can simply drop our custom code and switch to the C++11
classes. We distinguish regular and recursive mutexes, as the
latter don't work well with condition variables, which will be
introduced by a followup CL.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23625003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16416 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the shell sample don't print the result of executing a script, only
evaluating expressions.
Fixed issue when building samples on Windows using a shared V8
library. Added visibility option on Linux build which makes the
generated library 18% smaller.
Changed build system to accept multiple build modes in one build and
generate seperate objects, libraries and executables for each mode.
Removed deferred negation optimization (a * -b => -(a * b)) since this
visibly changes operand conversion order.
Improved parsing performance by introducing stack guard in preparsing.
Without a stack guard preparsing always bails out with stack overflow.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
