> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002
BUG=none
LOG=y
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/583153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We also initialize the Isolate on creation.
This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.
Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/469783002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Even although the Arm64 specification specifies that csp
only needs to be aligned to 16 bytes if it is dereferenced, some
implementations show poor performance.
Also makes the following change:
- Enable CPU support for arm64 to enable probing of cpu implementer and cpu part.
- Add ALWAYS_ALIGN_CSP CpuFeature for Arm64 and set it based on runtime probing of the cpu imp
- Rename PrepareForPush and PrepareForPop to PushPreamble and PopPostamble and move PopPostabl
Original Review URL: https://codereview.chromium.org/264773004R=ulan@chromium.org
Review URL: https://codereview.chromium.org/271543004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original descriptions were:
- "Refactor and cleanup VirtualMemory."
- "Fix typo."
- "Deuglify V8_INLINE and V8_NOINLINE."
- "Don't align size on allocation granularity for unaligned ReserveRegion calls."
Reasons for the revert are:
- Our mjsunit test suite slower by a factor of 5(!) in release mode.
- Flaky cctest/test-alloc/CodeRange on all architectures and platforms.
- Tankage of Sunspider by about 6% overall (unverified).
TBR=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/23970004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16662 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove a lot of platform duplication, and simplify the virtual
memory implementation. Also improve readability by avoiding bool
parameters for executability (use a dedicated Executability type
instead).
Get rid of the Isolate::UncheckedCurrent() call in the platform
code, as part of the Isolate TLS cleanup.
Use a dedicated random number generator for the address
randomization, instead of messing with the per-isolate random
number generators.
TEST=cctest/test-virtual-memory
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/23641009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16637 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
- New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
- Changes to enable oldspaces iteration without maps decoding:
-- layout change for FixedArrays: length is stored as a smis (initial patch by
Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on
arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not
computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special
way.
Review URL: http://codereview.chromium.org/2144006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
