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
This CL updates
StoreBuffer::FindPointersToNewSpaceOnPage such that it skips constant pool array objects. Constant Pool Arrays should never have pointers to the new space and might contain pointers to the FreeSpace map (e.g., due to code
being generated which needs to do a map-check on a FreeSpace object) which would incorrectly treated as a filler object if processed by FindPointersToNewSpaceOnPage().
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/183553003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19771 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The tests were using different kind of constructs for achieving the same
thing. This makes refactoring the compilation API more difficult than it should
be.
cctest.h already contained helpers for compiling and running scripts, but they
were not used consistently.
For example, all these were used for running scripts:
v8::Script::Compile(v8_str("foo"))->Run();
v8::Script::Compile(v8::String::NewFromUtf8(isolate, "foo))->Run();
CompileRun(v8_str("foo"));
CompileRun(v8::String::NewFromUtf8(some_way_to_get_isolate(), "foo"));
v8::Local<v8::Script> script = any_of_the_above; script->Run();
Most of the tests just want to run a script (which is in const char*) and don't
care about how the v8::String is constructed or passed to the compiler API. Using
the helpers makes the test more readable and reduces boilerplate code which is
unrelated to what the test is testing.
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/190503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- The regexp in the ParseObjectLiteralComment was wrong, made it less wrong (
it's still wrong since trailing commas are not required / allowed).
- Change in logic: In case we have "get somekeyword() { }", the "somekeyword"
was not logged as a symbol by PreParser and not expected in the preparser data
by Parser. This is unnecessary complication; in other contexts where keywords
are allowed as identifiers, they are logged as symbols (see
ParseIdentifierName).
BUG=v8:3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/173273006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19750 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r19715 (0d6d244)
Original commit message:
Lithium currently supports 3 division-like operations on integral
operands: "Normal" division (rounding towards zero), flooring division
(rounding towards -Infinity) and modulus calculation (the counterpart
for the "normal" division). For divisors which are a power of 2, one can
efficiently use some bit fiddling to avoid the actual division for such
operations. This CL cleanly splits off these operations into separate
Lithium instructions, making the code much more maintainable and more
consistent across platforms.
There are 2 basic variations of these bit fiddling algorithms: One
involving branches and a seemingly more clever one without branches.
Choosing between the two is not as easy as it seems: Benchmarks (and
probably real-world) programs seem to favor positive dividends,
registers and shifting units are sometimes scarce resources, and branch
prediction is quite good in modern processors. Therefore only the
"normal" division by a power of 2 is implemented in a branch-free
manner, this seems to be the best approach in practice. If this turns
out to be wrong, we can easily and locally change this.
BUG=
R=plind44@gmail.com
Review URL: https://codereview.chromium.org/189433008
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19733 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r19706 (81fd8dd)
Original commit message:
We can make more efficient code to check against type cells in the future if we use symbols, guaranteed not to conflict with user code. Currently, the "symbols" are the hole and undefined. Undefined may come in from the outside.
BUG=
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/189143006
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19726 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes about a few TODOs handled in this patch:
* In ProfileEntryHookStub::Generate:
Stubs are always called with relocation.
* In CreateArrayDispatchOneArgument:
The branches to registers can't be conditional. We could use a jump table, but
there are only 6 different kinds so it is likely not worth it.
* In Builtins::Generate_StringConstructCode:
Rename the argc register (x0) after its meaning changes.
Remove a TODO: using a macro would not make the code clearer.
* In Generate_JSEntryTrampolineHelper:
Remove the TODO and raise an internal issue to investigate this.
* In Disassembler::SubstituteBranchTargetField:
Print the target address, but we don't have more info on the target.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/185793002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19724 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When object is creating via native V8 API calls JS callstack is empty and the allocation is indistinguishable from say compiler allocations. This change adds a separate entry for such allocations.
Since FunctionInfo not necessarily corresponds to a heap object they are now referred to using their index in the list of all FunctionInfos.
BUG=chromium:277984
LOG=N
R=loislo@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/177203002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19718 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
