Fix concurrent osr.

InstallOptimizedCode aquires ownership on the compilation info and deletes
it on return, tearing down the attached zone.  The OptimizingCompiler
object is a zone object allocated in just that zone, so it also gets
deleted.  Effectively, InstallOptimizedCode cleans up when it's done, so
the OptimizingCompiler object it receives is invalidated afterwards.

R=titzer@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@16609 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove unused method HType::IsTagged().

BUG=
R=bmeurer@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@16610 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
HeapProfiler: very slow ~4min "take snapshot time" for 80MB gmail heap.

The reason of that is a number of cons strings in the app.
The app constructs a json string and as a result v8 heap has
a very long chain of cons strings.

Profiler counts all these strings as plain String objects and
assign the content of the strings as node names.

It required O(n^2) time and O(n^2) memory.

Solution: I introduced two new types, kConsString and kSliced string.
They do not use the content of the string for names. So the problem disappeared.

The heap profiler usability problem will be solved on Blink side.

BUG=285770
R=yangguo@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@16611 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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: https://v8.googlecode.com/svn/branches/bleeding_edge@16612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00