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 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 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
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
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
Two new methods are added to allow embedders to determine that execution
should be resumed at a particular point in the stack without being forced
to unwind all JS frames.
* V8::ResumeExecution() -- When execution is terminated via a call to
V8::TerminateExecution(), this method can be called to clear the
termination exception so that the engine can continue to be used.
* TryCatch::HasTerminated() -- When a TryCatch has caught a termination
exception, HasTerminated() will return true to indicate it is valid to
call V8::ResumeExecution() if desired.
A test case is added to cctest/test-thread-termination.cc.
BUG=v8:2361
Patch from Andrew Paprocki <andrew@ishiboo.com>.
Review URL: https://chromiumcodereview.appspot.com/11142013
Patch from Andrew Paprocki <andrew@ishiboo.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13218 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The approach in this change is to handle the unwrapping/wrapping of the global object transparently with respect to the JS implementation of Object.observe. An alternate approach would be to add a runtime method like %IsJSGlobalProxy and %UnwrapJSGlobalProxy, but it seems ugly to give JS (even implementation JS) access to the unwrapped global.
BUG=v8:2409
Review URL: https://codereview.chromium.org/11414094
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes how FunctionTemplate interprets a Signature that specifies
compatible receivers and arguments. Only the hidden prototype chain will
be considered when searching for compatible receivers. This prevents
JavaScript from modifying the inheritance relationship set up by the
embedder.
R=rossberg@chromium.org
BUG=v8:2268
TEST=cctest/test-api
Review URL: https://codereview.chromium.org/11308197
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13131 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- perform CPU profiler sampling in the sampler thread as we used to;
- skip sampling in the sampling thread if processing thread is running;
- only install SIGPROF handler when CPU profiling is enabled.
BUG=v8:2364
Review URL: https://codereview.chromium.org/11231002
Patch from Sergey Rogulenko <rogulenko@google.com> and Andrey Kosyakov <caseq@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12985 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To preserve ordering guarantees during end-of-turn delivery, Object.deliverChangeRecords needs to remove the delivered-to observer from the list of active observers.
The added test demonstrates this behavior.
Review URL: https://codereview.chromium.org/11410046
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12951 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL has two parts: the first is the logic itself, whereby each observer callback is assigned
a "priority" number the first time it's passed as an observer to Object.observe(), and that
priority is used to determine the order of delivery.
The second part invokes the above logic as part of the API, when the JS stack winds down to
zero.
Added several tests via the API, as the delivery logic isn't testable from a JS test
(it runs after such a test would exit).
Review URL: https://codereview.chromium.org/11266011
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This requires adding a new JSObject to the strong root list and populating it from
object-observe.js. The main other change is that we now directly use ObjectHashTable
from JS rather than using WeakMap, since using the latter would end up leaking whichever
Context initialized that observation state.
Added a test via the API showing that different contexts all end up working on the same state.
Review URL: https://codereview.chromium.org/11274014
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added highly efficient Object::SetAlignedPointerInInternalField and
Object::GetAlignedPointerFromInternalField functions for 2-byte-aligned
pointers. Their non-aligned counterparts Object::GetPointerFromInternalField and
Object::SetPointerInInternalField are now deprecated utility functions.
External is now a true Value again, with New/Value/Cast using a JSObject with an
internal field containing a Foreign. External::Wrap, and External::Unwrap are now
deprecated utility functions.
Added Context::GetEmbedderData and Context::SetEmbedderData. Deprecated
Context::GetData and Context::SetData, these are now only wrappers to access
internal field 0.
Added highly efficient Context::SetAlignedPointerInEmbedderData and
Context::GetAlignedPointerFromEmbedderData functions for 2-byte-aligned
pointers.
Review URL: https://codereview.chromium.org/11190050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This enables code flushing even with incremental marking enabled and
fully shares the function link field in JSFunctions between candidates
for code flushing and the optimized functions list. If a candidate for
code flushing gets optimized, it will be evicted from the candidates
list.
R=ulan@chromium.org
BUG=v8:1609
Review URL: https://codereview.chromium.org/11140025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12796 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In WebKit, we have a small integer cache because calling v8::Integer::New is
slow. This patch adds a faster API for creating integers that requires the
caller to supply the v8::Isolate, saving us the work of looking up the isolate
in thread-local storage.
BUG=
Review URL: https://codereview.chromium.org/11212004
Patch from Adam Barth <abarth@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12773 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This API lets the embedder enumerate handles that have class ids. WebKit will
use this feature during garbage collection to compute object groups for DOM
nodes. Previously, we kept a list of DOM nodes on the WebKit side, but that
list is redundant with the global handles list in V8.
Review URL: https://codereview.chromium.org/11190011
Patch from Adam Barth <abarth@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12750 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the speed of deserializing code. The current startup
time improvement for V8 is around 6%, but code deserialization
is speeded up disproportionately, and we will soon have more
code in the snapshot.
* Removed support for deserializing into large object space.
The regular pages are 1Mbyte now and that is plenty. This
is a big simplification.
* Instead of reserving space for the snapshot we actually
allocate it now. This removes some special casing from
the memory management and simplifies deserialization since
we are just bumping a pointer rather than calling the
normal allocation routines during deserialization.
* Record in the snapshot how much we need to boot up and
allocate it instead of just assuming that allocations in
a new VM will always be linear.
* In the snapshot we always address an object as a negative
offset from the current allocation point. We used to
sometimes address from the start of the deserialized data,
but this is less useful now that we have good support for
roots and repetitions in the deserialization data.
* Code objects were previously deserialized (like other
objects) by alternating raw data (deserialized with memcpy)
and pointers (to external references, other objects, etc.).
Now we deserialize code objects with a single memcpy,
followed by a series of skips and pointers that partially
overwrite the code we memcopied out of the snapshot.
The skips are sometimes merged into the following
instruction in the deserialization data to reduce dispatch
time.
* Integers in the snapshot were stored in a variable length
format that gives a compact representation for small positive
integers. This is still the case, but the new encoding can
be decoded without branches or conditional instructions,
which is faster on a modern CPU.
Review URL: https://chromiumcodereview.appspot.com/10918067
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).
An ownership bit is added to maps indicating whether it owns its own descriptor array or not.
Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.
Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.
To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.
We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.
When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.
Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.
When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10909007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- The global object has a reference to the current global scope chain.
Running a script adds to the chain if it contains global lexical declarations.
- Scripts are executed relative to a global, not a native context.
- Harmony let and const bindings are allocated to the innermost global context;
var and function still live on the global object.
(Lexical bindings are not reflected on the global object at all,
but that will probably change later using accessors, as for modules.)
- Compilation of scripts now needs a (global) context (previously only eval did).
- The global scope chain represents one logical scope, so collision tests take
the chain into account.
R=svenpanne@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/10872084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the positive lookup performed by these LoadICs, to use the
holder instead of the receiver to perfrom the lookup on. It also extends
this improvement to KeyedLoadICs. And it fixes a bug introduced for the
JavaScript getter case of a LoadIC.
R=erik.corry@gmail.com
BUG=chromium:142088
TEST=cctest/test-api/Regress142088,cctest/test-api/Regress137002b
Review URL: https://chromiumcodereview.appspot.com/10828303
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now a map points to a transition array which contains the descriptor array. The descriptor array is now immutable. The next step is to share the descriptor array with all back-pointed maps as long as there is a single line of extension. Maps that require a descriptor array but don't need transitions will still need a pseudo-empty transition array to contain the descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10816005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12298 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mksnapshot or a VM that is booted from a snapshot. --debug-code
can still have an effect on stub and optimized code and it still
works on the full code generator when running without snapshots.
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10834085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12239 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the traditional MIPS naming scheme, "mips" is used for
big-endian mips and "mipsel" is used for little-endian mips.
In V8 the "mips" build is little-endian, so the "mips" target is
renamed to "mipsel" to be compliant with the traditional MIPS
naming scheme.
This change is also required for supporting the Chromium project on MIPS.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10695114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
Review URL: https://chromiumcodereview.appspot.com/10697015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows to run tests on the attached Android device using
> make android.check
> make android.debug.check
> make android.release.check
> ANDROID_V8=/data/local/v8 TESTJOBS=-j4 make android.release.check -j10
Tests and binaries are copied to device location specified by the ANDROID_V8
variable and then tests are executed using the 'adb shell' program.
R=jkummerow@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10696048
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
