This includes:
- actually release handles kept by compilation info when compilation completes.
- do not use parallel recompilation on single core CPUs.
- artificially delay parallel recompilation for debugging.
- fix outdated assertions wrt optimization status.
- add "parallel" option to %OptimizeFunctionOnNextCall.
R=jkummerow@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/12442002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13827 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
This is a temporary workaround when the __proto__ property is being
redefined (e.g. by Object.freeze()) to not loose the foreign callback.
Once the __proto__ property is a real JavaScript accessor this hack is
no longer necessary. This change also makes __proto__ configurable.
R=rossberg@chromium.org
BUG=v8:2565
TEST=mjsunit/regress/regress-2565
Review URL: https://codereview.chromium.org/12398010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13817 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The new instance type 'Symbol' represents ES6 symbols (a.k.a. private/unique names). Currently, symbols are simple data objects that only carry a hash code, random-generated upon allocation.
The new type 'Name' now serves as the common super class for strings and symbols, and is supposed to represent property names. We will eventually migrate APIs from String to Name for the standard key type.
Strings and symbols share the same hash field representation, via the Name class. This way, we should be able to use the same code paths for symbols and internalized strings in most cases. Also, Symbol's instance type code is allocated adjacent to internalized string codes in the enum, allowing a simple range check for the common case.
Baseline CL: https://codereview.chromium.org/12210083/R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12223071
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the deoptimizer to materialize arguments objects of correct
length even in cases where the actual argument values are unknown and
were optimized away by Crankshaft. This can happen if only the length
property or the identity of an arguments object is used.
R=svenpanne@chromium.org
BUG=chromium:163530
TEST=mjsunit/regress/regress-crbug-163530
Review URL: https://codereview.chromium.org/12335132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13763 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, we would disassemble some VFP instructions like this:
vmla.f64eq d16, d17, d18
This patch moves the condition to the right place:
vmlaeq.f64 d16, d17, d18
Spotted by Rodolph Perfetta!
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12335129
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13752 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch is based on the previous one that was rolled out: https://code.google.com/p/v8/source/detail?r=12985
On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow.
CPU profiler continues to use SamplingCircularQueue, we will replave it with a single sample buffer when Mac and Win ports support profiling on the event processing thread.
When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the SignalSender thread as it used to if no CPU profiles are being collected.
ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point.
BUG=v8:2364
Review URL: https://codereview.chromium.org/12321046
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The reason this test fails on ARM hardware but not on Intel hardware
(including the ARM simulator) is this:
'\xa0' is interpreted as a negative signed byte number. Casting it to
uc16 sign-extends it. The resulting string does not fit into a one-byte
string, thus a two-byte string is allocated.
For some reason the code compiled for ARM does not sign-extend, and 0xa0
fits into a one-byte string. Thus a one-byte string is allocated. Trying
to cast it to two-byte causes assertion failure.
BUG=
Review URL: https://chromiumcodereview.appspot.com/12319111
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This moves the __proto__ property to Object.prototype and turns it into
a callback property actually present in the descriptor array as opposed
to a hack in the properties lookup. For now it still is a "magic" data
property using foreign callbacks and not an accessor property visible to
JavaScript.
The second effect of this change is that JSON.parse() no longer treats
the __proto__ property specially, it will be defined as any other data
property. Note that object literals still have their special handling.
R=rossberg@chromium.org
BUG=v8:621,v8:1949,v8:2441
TEST=mjsunit,cctest,test262
Review URL: https://codereview.chromium.org/12212011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When there are interceptors on an object, it's possible to
end up with duplicate property names. But when all the names
are provided by v8, a collision is not possible, so we can
fast-path that case by not de-duping.
Also added better test coverage for interceptor API.
Review URL: https://codereview.chromium.org/12314081
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13725 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
The assembler has 8 different vmov variants. The one for vmov.32 and for moving
an immediate into a double reg only differs in the type of the second
paremeter: vmov.32 takes an int, the other takes a double.
The situation is dangerous because C++ will happily implicitly convert between
int and double.
This patch changes the signature of the vmov.32 assembler function so that it
cannot be confused with the other vmovs.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12255031
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows Crankshaft to completely inline a f.apply() dispatch if the
exact number of arguments is known and the function is constant. The
deoptimizer doesn't generate the f.apply() frame during deoptimization,
so the materialized frames look like f.apply() did a tailcall.
R=jkummerow@chromium.org
TEST=mjsunit/compiler/inline-function-apply
Review URL: https://codereview.chromium.org/12263004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes a corner case where the code flusher is disabled while the
incremental marker is still running. This can happen when the debugger
is loaded and a scavenge is triggered. Make sure that all flushing
decisions are revisited after the candidates lists are evicted.
R=hpayer@chromium.org
BUG=chromium:173458,chromium:168582
TEST=cctest/test-heap/Regress173458
Review URL: https://codereview.chromium.org/12217108
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13641 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
object-observe.js uses weak maps to add "hidden" properties to
objects. Previously, the hash tables it was using weren't actually
weak. This patch changes the existing runtime functions to create
instances of JSWeakMap instead of exposing ObjectHashTable directly.
Review URL: https://codereview.chromium.org/12092079
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13591 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a data property has its attributes changed but its value remains the same,
don't emit an oldValue. This makes the API more consistent by only emitting
oldValue when the value of a property has actually changed (or been removed,
in the case of a reconfiguration as an accessor property or a deletion).
Review URL: https://codereview.chromium.org/11820004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes a corner case that happens when JSFunctions are enqueued as
code flushing candidates but their respective SharedFunctionInfo isn't.
If the JSFunction gets evicted due to optimization the code slot in the
SharedFunctionInfo will never be recorded in the slots buffer.
R=hpayer@chromium.org
BUG=chromium:168801
TEST=cctest/test-heap/Regress168801
Review URL: https://codereview.chromium.org/11896064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13481 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
HCheckPrototypeMaps currently records the prototype and the holder of the
prototype chain (both ends of the chain) and assumes that the chain elements
and their maps did not change in during the entirety of Crankshaft. The actual
traversal of the prototype chain happens in Lithium at code generation.
With parallel compilation, this assumption is not longer correct.
R=mstarzinger@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/11864013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Note that leaving out the Isolate parameter previously had a very special
meaning, namely "use the *default* Isolate", i.e. the one magically created at
program initialization time. All other API entries use the meaning "current
Isolate", which is different in a multi-threaded setting and confusing.
Temporarily disabled deprecations until Chrome is ready.
BUG=v8:2487
Review URL: https://codereview.chromium.org/11970009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13419 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removed the following deprecated functions:
* Object::GetPointerFromInternalField
* Object::SetPointerInInternalField
* External::Wrap
* External::Unwrap
* Context::GetData
* Context::SetData
They have been deprecated in the 3.15 branch and are not used by Chrome anymore.
Furthermore, judging from bug reports and email threads, embedders like node.js
and others are already using 3.15, too. All removed API entries can be emulated
by a one-liner, so adapting should not be hard for anybody.
We want to introduce more deprecations soon, but to keep things simple and avoid
having old and not-so-old deprecations in v8.h, the 3.15 deprecations are now
removed.
In general, the strategy of keeping deprecated things for one stable release and
then removing them seems to be a good compromise between a maintenance nightmare
and annoying external embedders. :-)
Review URL: https://codereview.chromium.org/11885019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13372 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Flattening strings is relatively costly and by doing it after every duplication
we avoid combinatorial explosion.
Note that flattening could have been done by e.g. using a regular expression,
too, but this is just another implementation detail and %FlattenString seems
general enough to be useful in other tests, too.
Review URL: https://codereview.chromium.org/11828014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13337 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
