Add new "Name" type to API that is a supertype of Symbol and String.
Object::SetDeclaredAccessor, Object::SetAccessorProperty, Template::Set,
Template::SetAccessorProperty, and Template::SetDeclaredAccessor now
take a Name as the property name instead of a String.
Add Object::SetAccessor, Template::SetNativeDataProperty, and
ObjectTemplate::SetAccessor overloads that can define accessors for
symbol-named properties.
R=dcarney@chromium.org, rossberg@chromium.org
BUG=v8:3394
TEST=cctest/test-api/TestSymbolProperties
LOG=Y
Review URL: https://codereview.chromium.org/459413002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL updates RelocInfo update operations and set_target_address_at to enable
skipping of the icache flush if it going to be batched up later.
Code::CopyFrom and Code::Relocate are modified to avoid individual icache
flushes since the whole code area will be flushed after the reloc info is
updated.
These changes reduce a regression when enabling the OOL constant pool on Arm,
since this change can cause MovT/MovW instructions for relocatable targets
if the constant pool is full.
Scores for Mandreel latency on a Nexus 5:
- OOL CP disabled: 3533
- OOL CP enabled, without this CL: 1825
- OOL CP enabled, with change: 3015
R=rodolph.perfetta@arm.com, ulan@chromium.org
Review URL: https://codereview.chromium.org/284153004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21380 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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 and even the CPU features will be per-Isolate
later. Currently we get away with global state, because mksnapshot
runs single-threaded and has only 1 Isolate, but this will change.
Furthermore, these changes are yet another prerequisite for removing a
catch-22 at initialization time when we try to enable serialization.
This CL is similar in spirit to r20919, BTW.
BUG=359977
LOG=y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/250553005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20963 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch includes 3 fixes for veneers emission.
1) Block veneer pools emission in the PatchingAssembler.
2) Fix the check for veneer pool emission just before a constant pool.
3) Forbid copy of labels. The list of JumpTableEntry used to track the
deoptimization table entries would make copies of the labels when growing.
Doing so, it would confuse the Assembler that was tracking the labels via
pointers.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/200133002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL enables RelocInfo pointers which live in the constant pool to be treated
as normal pointers by the slot buffer, avoiding the requirement of creating fake
RelocInfo objects during UpdateSlots() in order to update these slots. This
is possible because constant pool entries are just pointers and don't require
the RelocInfo machinary to be updated.
EmbeddedObject constant pool entries can be added untyped to the slot buffer,
while code targets are still typed in order to correctly update the target
address based on the relocated code object.
Note: this is required in order to enable OOL constant pool support on Arm, but
should be benifitial for the current inline constant pool used by Arm code.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/179813005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19772 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It was only used for Math.log, and even then only in full code and in %_MathLog. For crankshafted code, Intel already used the FP operations directly, while the ARM/MIPS ports were a bit lazy and simply called the stub. The latter directly call the C library now without any cache. It would be possible to directly generate machine code if somebody has the time, from what I've seen out in the wild it should be only about a dozen instructions.
LOG=y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/113343003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18344 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
To keep the structure of the serializer more or less untouched, we use
some ingenious Corry-approved(TM) 3-step technology (a.k.a. "hack"):
* Create copies of code objects.
* Wipe out all absolute addresses in these copies.
* Write out the cleaned copies instead of the originals.
In conjunction with --random-seed, our snapshots are reproducible now.
BUG=v8:2885
R=bmeurer@chromium.org, erik.corry@gmail.com
Review URL: https://codereview.chromium.org/54823002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, the result of target_reference_address() could only be
read, writing to it would have had an architecture-dependent effect,
e.g. writing into the code on ia32, a no-op on arm, etc.
This refactoring-only CL turns this into a simple getter, making it
impossible to use incorrectly.
More to come...
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/46583006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17467 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change means that code which is never executed is garbage collected immediately, and code which is only executed once is collected more quickly (limiting heap growth), however, code which is re-executed is reset to the young age, thus being kept around for the same number of GC generations as currently.
BUG=280984
R=danno@chromium.org, hpayer@chromium.org
Review URL: https://codereview.chromium.org/23480031
Patch from Ross McIlroy <rmcilroy@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Allocations of AllocationSites occur in generated code, so generated code needs to be able to add to the list. For now I have a special hydrogen instruction, though it would be nice to use general purpose instructions.
* The snapshot contains AllocationSites, and these need to be re-threaded into the list on deserialization.
Something nice is that the AllocationSites are only created in old space, so a special new space visitor isn't required.
BUG=
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/18173013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change modifies code produced by BaseLoadStubCompiler::GenerateLoadCallback so that instead of calling AccessorGetter direcly it calls InvokeAccessorGetter which changes VM state and calls the actual callback. This way CPU profiler knows which external callback is being executed in this case. Indirect call happens only if CpuProfiler::is_profiling() is true.
This is exactly same change as r15116 with a build fix for test-api.cc
BUG=244580
TBR=danno@chromium.org
Review URL: https://codereview.chromium.org/16858013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts commit f323d984a73bab345c4eab5c1907552ccfa7ccaa.
Broke compilation on the bots with an error that doesn't occur locally:
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-bignum-dtoa.o
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = int]’:
../test/cctest/test-api.cc:1129: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = unsigned int]’:
../test/cctest/test-api.cc:1136: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = double]’:
../test/cctest/test-api.cc:1143: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = bool]’:
../test/cctest/test-api.cc:1150: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = void]’:
../test/cctest/test-api.cc:1157: error: insufficient contextual information to determine type
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-circular-queue.o
BUG=None
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16838013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* adding the CODE_ADD_LINE_POS_INFO, CODE_START_LINE_INFO_RECORDING, CODE_END_LINE_INFO_RECORDING event and the corresponding functionality.
* adding the JITCodeLineInfo struct to record the code line info. I added this definition because Danno mentioned that "we'd like to cleanup and decouple the external debugging functionality"
* some other small changes.
Review URL: https://chromiumcodereview.appspot.com/12223027
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13686 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
