Traditionally, we cross compile a snapshot iff the serializer is enabled.
This will change in the future.
Changes:
- CpuFeatures probing is done once per process, depending on whether we
cross compile.
- CpuFeatures are consolidated into the platform-independent assembler.h
as much as possible.
- FLAG_enable_<feature> will only be checked at probing time (already the
case for ARM).
- The serializer state is cached by the MacroAssembler.
- PlatformFeatureScope is no longer necessary.
- CPUFeature enum values no longer map to CPUID bit fields.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/285233010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21347 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The serializer state has to be per-Isolate, but at the point where we
generate our memmoves we don't really have an Isolate. Furthermore,
there was no fundamental reason why we shouldn't use our home-grown
memmove during mksnapshot time.
Perhaps we can totally remove our own memmove nowadays, but this would
be a separate CL.
BUG=359977
LOG=y
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/261903002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We don't use the worker pool yet, however, there are tests. Yay. The
next step is to use the worker pool for parallel sweeping.
I've also started to move the platform related files into a sub
directory. The goal is to eventually build all the platform stuff as
a separate library which is used by d8 and cctest (and other embedders
that wish to use the default implementation) but not by chromium.
BUG=v8:3015
R=hpayer@chromium.org, svenpanne@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/104583003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18380 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Based on prototype at
https://github.com/rossberg-chromium/js-promise
which informed the latest spec draft version at
https://github.com/domenic/promises-unwrapping/blob/master/README.md
Activated by --harmony-promises.
Feature complete with respect to the draft spec, plus the addition of .when and .deferred methods. Final naming and other possible deviations from the current draft will hopefully be resolved soon after the next TC39 meeting.
This CL also generalises the Object.observe delivery loop into a simplistic microtask loop. Currently, all observer events are delivered before invoking any promise handler in a single fixpoint iteration. It's not clear yet what the final semantics is supposed to be (should there be a global event ordering?), but it will probably require a more thorough event loop abstraction inside V8 once we get there.
R=dslomov@chromium.org, yhirano@chromium.org
BUG=
Review URL: https://codereview.chromium.org/64223010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes tons of architecture-specific code and makes it easy to
experiment with other pseudo-RNG algorithms. The crankshafted code is
extremely good, keeping all things unboxed and doing only minimal
checks, so it is basically equivalent to the handwritten code.
When benchmarks are run without parallel recompilation, we get a few
percent regression on SunSpider's string-validate-input and
string-base64, but these benchmarks run so fast that the overall
SunSpider score is hardly affected and within the usual jitter. Note
that these benchmarks actually run even faster when we don't
crankshaft at all on the main thread (the regression is not caused by
bad code, it is caused by Crankshaft needing a few hundred microsecond
for compilation of a trivial function). Luckily, when parallel
recompilation is enabled, i.e. in the browser, we see no regression at
all!
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/68723002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
