Skip to content

V
V8
Switch branch/tag
  1. 14 Jan, 2014 1 commit
  3. 23 Sep, 2013 1 commit
  5. 13 Sep, 2013 1 commit
  7. 11 Sep, 2013 3 commits
  9. 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
  11. 05 Sep, 2013 1 commit
  13. 02 Sep, 2013 1 commit
  15. 29 Aug, 2013 2 commits
  17. 28 Aug, 2013 6 commits
  19. 31 Jul, 2013 1 commit
  21. 30 Jul, 2013 1 commit
  23. 25 Jul, 2013 3 commits
  25. 23 Jul, 2013 2 commits
  27. 12 Jul, 2013 1 commit
  29. 11 Jul, 2013 1 commit
  31. 05 Jul, 2013 1 commit
  33. 28 Jun, 2013 1 commit
  35. 20 Jun, 2013 1 commit
  37. 19 Apr, 2013 1 commit
  39. 16 Apr, 2013 1 commit
  41. 12 Apr, 2013 1 commit
  43. 11 Apr, 2013 1 commit
  45. 10 Apr, 2013 2 commits
    • yurys@chromium.org's avatar
      Remove profiler thread related methods from RuntimeProfiler · 46508ec2
      yurys@chromium.org authored 
      Now that V8 doesn't use sampling thread for optimizations
the methods can be removed.

BUG=None

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14214 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      46508ec2
    • yurys@chromium.org's avatar
      Add sanity test for CPU profiler · c7ce87f8
      yurys@chromium.org authored 
      The new test checks full CPU profiling cycle: using public
V8 API it starts profiling, executes a script, stops profiling
and analyzes collected profile to check that its top-down
tree has expected strutcture. The script that is being profiled
is guaranteed to run > 200ms to make sure enough samples
are collected.

To avoid possible flakiness due to non-deterministic time required
to start new thread on varios OSs when Sampler and ProfilerEventsProcessor
threads are being started the main thread is blocked until the threads
are running.

Also I removed the heuristic in profile-generator.cc where we try
to figure out if the value on top of the sampled stack is return address
of some frameless stub invocation. The code periodically gives false positive
with the new test ending up in an extra node in the collected cpu profile.
After discussion with jkummerow@ we concluded that the logic is too fragile
and that we can address frameless stub invocations in a more reliable way
later should they have a noticeable effect on cpu profiling.

BUG=None

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14205 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c7ce87f8
  47. 02 Apr, 2013 1 commit
  49. 21 Mar, 2013 1 commit
  51. 19 Mar, 2013 1 commit
  53. 07 Mar, 2013 1 commit
  55. 26 Feb, 2013 1 commit
    • yurys@chromium.org's avatar
      Send SIGPROF signals on the profiler event processor thread · dc9b8176
      yurys@chromium.org authored 
      The patch is based on the previous one that was rolled out: https://code.google.com/p/v8/source/detail?r=12985

On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow.

CPU profiler continues to use SamplingCircularQueue, we will replave it with a single sample buffer when Mac and Win ports support profiling on the event processing thread.

When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the  SignalSender thread as it used to if no CPU profiles are being collected.

ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point.

BUG=v8:2364

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      dc9b8176