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
There are now NONE and NONE64 RelocInfo types, but only ARM uses them
both at the same time. They were added in:
https://chromiumcodereview.appspot.com/11191029/
I'll rename NONE to NONE32 in a later CL.
This CL cleans up the RelocInfo::NONE usage by:
- Using RelocInfo::IsNone when testing for NONE-ness.
- Using NONE on 32-bit platforms (MIPS and IA32), and NONE64 on 64-bit
platforms (x64).
This cleans up the code and prevents it from evolving bugs in the future
because NONE32 and NONE64 are used in misleading ways.
R= ulan@chromium.org
Review URL: https://chromiumcodereview.appspot.com/11695006
Patch from JF Bastien <jfb@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13307 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Access to an ExternalReference in non-serializable code will try to use
an offset relative to the root-array register.
Since the root-array is in the Heap object, and the Heap object is in
the Isolate object, there's a good chance that any external data field
is within a 32-bit offset of the root array register.
It falls back on the original behavior if the serializer is enabled,
if the root register isn't initialized or if the offset is not representable
as a 32-bit value.
Review URL: http://codereview.chromium.org/6716018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
we know that both sides are Smi and those where we don't. Fix inlined
symbol table probes to cope with strings, undefined and null (indicating
a deleted entry). Some changes to other architectures that were found
with the new asserts.
Review URL: http://codereview.chromium.org/6682026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7172 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
