Also, as this is hard to track down, always DCHECK position after ReadBlock().
Change-Id: Ie32c3a311dd8df91f651b6d82ccacc7c95e6fde0
Reviewed-on: https://chromium-review.googlesource.com/528196
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45811}
Do not allow that holey properties are defined in Array sort.
Throw a type error if the array is not extensible and there are holey
properties in the middle of the array.
BUG=v8:4888
Review-Url: https://codereview.chromium.org/2664173002
Cr-Commit-Position: refs/heads/master@{#43126}
This syntax was formerly legal per ECMAScript, but has been a
SyntaxError for some time now. V8 deviates from spec in that it
is instead a runtime error; we'd like to know if we can get
away with removing it (at least in sloppy mode) or if the spec
should be changed.
c.f. https://github.com/tc39/ecma262/issues/257#issuecomment-195106880
Also add self to authors file
BUG=v8:4480
Review-Url: https://codereview.chromium.org/2599253002
Cr-Commit-Position: refs/heads/master@{#41960}
Currently when the number passed to TryNumberToSize is 1 << 64,
it gets away with a bug caused by rounding of mantissa.
Then the number will be casted to 0 and TryNumberToSize
will return true. This patch fix this by making the range check
more accurate.
BUG=v8:5712
Review-Url: https://codereview.chromium.org/2548243004
Cr-Commit-Position: refs/heads/master@{#41578}
The latter was left from a previous commit and not updated later to reflect the new name.
Review-Url: https://codereview.chromium.org/2447023004
Cr-Commit-Position: refs/heads/master@{#40620}
Port d61a5c376b
Original commit message:
As a first step I uncommit the memory on the main thread. Also
to measure impact and stability of that optimization. In a
follow-up CL, the uncommitting should be moved on the concurrent thread.
R=jochen@chromium.org, hpayer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2245703002
Cr-Commit-Position: refs/heads/master@{#38654}
Currently the code example in the FunctionTemplate class documentation
is out of date. This commit updates the examples so they compile and run
without error.
BUG=
Review-Url: https://codereview.chromium.org/2127523003
Cr-Commit-Position: refs/heads/master@{#37741}
Since python3 does not use the old print statement, it may not be able
to load gdb-v8-support.py script in gdb as below:
(gdb) source tools/gdb-v8-support.py
File "tools/gdb-v8-support.py", line 170
print result
^
SyntaxError: Missing parentheses in call to 'print'
This fixes print statement for both python2 and python3.
R=jochen@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2084163004
Cr-Commit-Position: refs/heads/master@{#37488}
Reporting use counts by invoking a callback once per occurrence has
a large overhead cost in certain situations, for example when it needs
to be dispatched to a different thread (which is the case for Web Workers).
Parsing large scripts can produce a lot of occurrences (strict/sloppy mode
once per function).
Chromium (the only known user of UseCounters so far) does not actually care
about number of occurrences, but simply whether they happened at least once.
This commit changes behavior to report features at most once, which dramatically
improves performance for impacted use cases, and should not affect the only
known real world usage.
R=littledan@chromium.org
BUG=chromium:614775
Review-Url: https://codereview.chromium.org/2062203002
Cr-Commit-Position: refs/heads/master@{#36979}
The current code for testing the VEX.L flag, indicating whether
128-bit or 256-bit registers are being accessed, was erroneous
and always returned true (i.e. indicated 128-bit registers).
This patch fixes this behaviour and checks the flag correctly.
Ref: https://github.com/nodejs/node/issues/6151
BUG=
Review URL: https://codereview.chromium.org/1875323002
Cr-Commit-Position: refs/heads/master@{#35506}
ARM specific CONFIG_KUSER_HELPERS kernel feature for Linux can be disabled,
and in this case, we shouldn't crash. Use a __sync_synchronize() call
instead for Linux platforms.
BUG=chromium:599051
LOG=Y
Review URL: https://codereview.chromium.org/1840203004
Cr-Commit-Position: refs/heads/master@{#35170}
After histrogram timer added time recaling functionality,
some events, e.g. parse, histogram timer generates event log ending with 'MicroSeconds'.
Since ProfViz can't recorgnize it, this patch cuts off 'MicroSeconds' postfix.
R=vogelheim@chromium.org, yangguo@chromium.org
BUG=chromium:
LOG=N
Review URL: https://codereview.chromium.org/1771293002
Cr-Commit-Position: refs/heads/master@{#34710}
Most libraries use `JSON.stringify` with all three arguments [1] to allow for
configuration, even if `replacer` and `space` are falsey, causing the
optimized native stringifying to be missed. This commit allows for the common
case where `replacer` and `space` are not used to be fast.
[1]: https://github.com/hapijs/hapi/pull/3014
BUG=v8:4730
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1710933002
Cr-Commit-Position: refs/heads/master@{#34174}
Without this change, the v8::Local<> constructor will be picked up by the
compiler as an option for an implicit cast for any pointer type. This leads
to bad error messages when accidentally passing an erroneous pointer type to
a function wanting a Local<> (complains about a pointer assignment in Local<>'s
constructor as opposed to a bad type for the parameter of the function being
called) and also causes ambiguity errors where none should exist when calling
overloaded functions (for example a function taking either a std::string or a
v8::Local<v8::Script> cannot be called with a const char * because the compiler
sees both types as being constructable with a const char *).
R=jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1647833005
Cr-Commit-Position: refs/heads/master@{#33602}
BUG=
A bug in android-sync.sh, which caused the android_arm.release.check
unittests crash on device. It is fixed by adding:
sync_file "$OUTDIR/$ARCH_MODE/natives_blob.bin"
sync_file "$OUTDIR/$ARCH_MODE/snapshot_blob.bin"
Review URL: https://codereview.chromium.org/1616393002
Cr-Commit-Position: refs/heads/master@{#33578}
If many threads use the same Isolate (or many Isolates) and then
terminate, their PerIsolateThreadData objects are never cleaned
up, resulting in a slow memory leak and, worse, the
PerIsolateThreadData chain getting larger and larger, adversely
affecting performance.
In this situation, embedders will now be encouraged to apply
DiscardThreadSpecificMetadata against any Isolate a thread is
done with, especially if the thread is about to terminate.
Note that it is harmless to run DiscardThreadSpecificMetadata
against an Isolate for which a thread has no thread data and
per-Isolate thread data can be reestablished if a thread starts
using an Isolate again after running DiscardThreadSpecificMetadata
against it.
It is, however, an embedder error to run
DiscardThreadSpecificMetadata against an Isolate in thread with a
Locker for the Isolate in the stack or against an Entered Isolate.
This change cannot cause any change in behavior in existing apps
as the only added coded can only be reached via the new
DiscardThreadSpecificMetadata method.
R=Jakob, jochen
BUG=
Review URL: https://codereview.chromium.org/1522703002
Cr-Commit-Position: refs/heads/master@{#32909}
Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object.
R=machenbach@chromium.org,jkummerow@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/1435643002
Cr-Commit-Position: refs/heads/master@{#31964}
Section 8.10.5 9a specifies that a property descriptor cannot both have
accessors and specify the writability of the property. The previous
error message was misleading because it referred to writable rather
than specifying the writability (which includes writable: false).
BUG=v8:2536
LOG=N
Review URL: https://codereview.chromium.org/1399693003
Cr-Commit-Position: refs/heads/master@{#31273}
Since https://codereview.chromium.org/366103005 the promise tests null out
various globals, to ensure the promise implementation doesn’t itself rely
on functions patchable by monkeys.
Unfortunately, doing so breaks test assertion failures which rely on
those globals.
This isn’t the ideal solution, but does improve the current state.
R=littledan@chromium.org,domenic@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1370583002
Cr-Commit-Position: refs/heads/master@{#30922}
Uses the lower byte with memchr which is
significantly faster than a naive compare
Performance difference with bench (http://hastebin.com/xuxexataso.js):
old new
single character single character
Κ found at 922 Κ found at 922
3324 616
㎡ found at 13217 ㎡ found at 13217
42366 4931
က found at 4096 က found at 4096
13369 9836
found at 65280 found at 65280
207472 36149
ﾥ found at 65445 ﾥ found at 65445
209344 36666
found at 8197 found at 8197
26731 11757
倂 found at 20482 倂 found at 20482
66071 17193
linear search linear search
ΚΛ found at 922 ΚΛ found at 922
4112 504
㎡㎢ found at 13217 ㎡㎢ found at 13217
55105 5119
ﾥﾦ found at 65445 ﾥﾦ found at 65445
268016 35496
linear + bmh search linear + bmh search
ΚΛΜΝΞΟΠΡ found at 922 ΚΛΜΝΞΟΠΡ found at 922
2897 522
ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445 ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445
167687 35283
BUG=
Review URL: https://codereview.chromium.org/1324453007
Cr-Commit-Position: refs/heads/master@{#30597}
Reason for revert:
[Sheriff] Breaks fuzzer and msan:
http://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/4773
Repro with:
tools/fuzz-harness.sh out/Debug/d8
(in a ninja Debug build)
Msan:
http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/4097
Original issue's description:
> Speedup stringsearch for two byte strings
>
> Uses the lower byte with memchr which is
> significantly faster than a naive compare
>
> Performance difference with bench (http://hastebin.com/xuxexataso.js):
>
> old new
>
> single character single character
> Κ found at 922 Κ found at 922
> 3324 616
> ㎡ found at 13217 ㎡ found at 13217
> 42366 4931
> က found at 4096 က found at 4096
> 13369 9836
> found at 65280 found at 65280
> 207472 36149
> ﾥ found at 65445 ﾥ found at 65445
> 209344 36666
> found at 8197 found at 8197
> 26731 11757
> 倂 found at 20482 倂 found at 20482
> 66071 17193
>
> linear search linear search
> ΚΛ found at 922 ΚΛ found at 922
> 4112 504
> ㎡㎢ found at 13217 ㎡㎢ found at 13217
> 55105 5119
> ﾥﾦ found at 65445 ﾥﾦ found at 65445
> 268016 35496
>
> linear + bmh search linear + bmh search
> ΚΛΜΝΞΟΠΡ found at 922 ΚΛΜΝΞΟΠΡ found at 922
> 2897 522
> ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445 ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445
> 167687 158465
>
> Committed: https://crrev.com/fced280f37588f8a232a414201276e053117e9ea
> Cr-Commit-Position: refs/heads/master@{#30587}
TBR=danno@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org,karl@skomski.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1331433002
Cr-Commit-Position: refs/heads/master@{#30588}
Uses the lower byte with memchr which is
significantly faster than a naive compare
Performance difference with bench (http://hastebin.com/xuxexataso.js):
old new
single character single character
Κ found at 922 Κ found at 922
3324 616
㎡ found at 13217 ㎡ found at 13217
42366 4931
က found at 4096 က found at 4096
13369 9836
found at 65280 found at 65280
207472 36149
ﾥ found at 65445 ﾥ found at 65445
209344 36666
found at 8197 found at 8197
26731 11757
倂 found at 20482 倂 found at 20482
66071 17193
linear search linear search
ΚΛ found at 922 ΚΛ found at 922
4112 504
㎡㎢ found at 13217 ㎡㎢ found at 13217
55105 5119
ﾥﾦ found at 65445 ﾥﾦ found at 65445
268016 35496
linear + bmh search linear + bmh search
ΚΛΜΝΞΟΠΡ found at 922 ΚΛΜΝΞΟΠΡ found at 922
2897 522
ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445 ﾥﾦﾧﾨﾩﾪﾫﾬ found at 65445
167687 158465
Review URL: https://codereview.chromium.org/1303033012
Cr-Commit-Position: refs/heads/master@{#30587}
The following errors come up when compiling v8
with clang 3.7 on FreeBSD/amd64:
src/runtime/runtime-i18n.cc:629:37: error: reinterpret_cast from
'nullptr_t' to 'v8::internal::Smi *' is not allowed
local_object->SetInternalField(1, reinterpret_cast<Smi*>(NULL));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test/cctest/test-heap.cc:131:20: error: reinterpret_cast from
'nullptr_t' to 'v8::internal::Object *' is not allowed
Handle<Object> n(reinterpret_cast<Object*>(NULL), isolate);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test/cctest/test-heap.cc:1989:18: error: reinterpret_cast from
'nullptr_t' to 'Address' (aka 'unsigned char *') is not
allowed
Address base = reinterpret_cast<Address>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+add myself to the AUTHORS file.
BUG=
Review URL: https://codereview.chromium.org/1277353002
Cr-Commit-Position: refs/heads/master@{#30103}
NumberFormat previously just used a min of 0 digits after the decimal and a max of 3. This CL changes it so that we use the ICU currency data, and set the min and max to the number of numbers after the decimal point for each currency.
This CL also fixes a small bug where if the minimum fraction digits is above 3 but the maximum fraction digits isn't set, then it returns with only three numbers after the decimal point.
BUG=435465,473104,304722
LOG=Y
Review URL: https://codereview.chromium.org/1231613006
Cr-Commit-Position: refs/heads/master@{#29734}
Reason for revert:
[Sheriff] This breaks layout test expectations:
http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2032/builds/437
See:
https://storage.googleapis.com/chromium-layout-test-archives/V8-Blink_Linux_32/437/layout-test-results/fast/dom/create-element-after-stack-overflow-pretty-diff.html
Please land a needsmanualrebaseline change on the blink-side before relanding this, if the change was intended.
Please include a blink trybot on relanding this.
Original issue's description:
> Added constructor call on object in InstantiateObject method
>
> I found after upgrading from 4.2.2 where apinatives.js still
> existed to 4.4.56 where everything had been converted to C++ in
> api-natives.cc, my constructors for ObjectTemplate instantiated objects
> were no longer being called. After investigation, I noticed in
> apinatives.js that a new call would handle that, but there was no
> corresponding constructor call in api-natives.cc (or anywhere else
> along the chain of InstantiateObject), so I added a call to
> Execution::Call to actually construct the object. Forgive me if that
> isn't the right place to add it (InitializeBody in objects-inl.h also
> looked like a good place), or if there's a reason constructors are
> not being called.
>
> I also added myself to the AUTHORS file in this CL.
>
> Committed: https://crrev.com/e61a957b2a9726294cdd2802a6a2b6e3a9ef657d
> Cr-Commit-Position: refs/heads/master@{#29076}
TBR=verwaest@chromium.org,svenpanne@chromium.org,dtalley@gmail.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1188233002
Cr-Commit-Position: refs/heads/master@{#29085}
I found after upgrading from 4.2.2 where apinatives.js still
existed to 4.4.56 where everything had been converted to C++ in
api-natives.cc, my constructors for ObjectTemplate instantiated objects
were no longer being called. After investigation, I noticed in
apinatives.js that a new call would handle that, but there was no
corresponding constructor call in api-natives.cc (or anywhere else
along the chain of InstantiateObject), so I added a call to
Execution::Call to actually construct the object. Forgive me if that
isn't the right place to add it (InitializeBody in objects-inl.h also
looked like a good place), or if there's a reason constructors are
not being called.
I also added myself to the AUTHORS file in this CL.
Review URL: https://codereview.chromium.org/1137693003
Cr-Commit-Position: refs/heads/master@{#29076}
The modified assertions targeted the property descriptor for the
template object's first "cooked" value. The code immediately preceeding
these statements asserts these values.
Update the assertions to instead target the property descriptor for the
template object's first "raw" value (which are otherwise untested).
BUG=
Review URL: https://codereview.chromium.org/1049523003
Cr-Commit-Position: refs/heads/master@{#27566}
e8b9f2d7 introduced a different cast which broke building on Illumos.
Revert to previous behavior for V8_OS_SOLARIS only.
Found on SmartOS while building with gcc 4.9.0.
edit1: adding jochen to reviewers since he was assigned through the issue tracker and danno since he seems to do a fair amount of cross-platform work
edit2: removing BUG reference because I don't understand what LOG needs to contain (and it seems to link to chromium and not the v8 repo). Please edit commit message as appropriate.
BUG=3935
LOG=n
Review URL: https://codereview.chromium.org/990063002
Cr-Commit-Position: refs/heads/master@{#27163}
Problem:
Excuting with flags as "--prof --logfile-per-isolate --logfile=/path/to/filename"
expected file name: /path/to/isolate-<isolate id>-filename
current result: isolate-<isolate id>-/path/to/filename
This patch makes the file name we expected.
Review URL: https://codereview.chromium.org/960813004
Cr-Commit-Position: refs/heads/master@{#26955}
Currently the derived type of a right shift does not narrow the input
type based on the actual shift amount - well it does some narrowing
but more can be down. For patterns such as u32[i>>2], which is very
common is asm.js code, this limits the ability to later prove that an
index bounds check is unnecessary which can have a significant
performance impact.
Review URL: https://codereview.chromium.org/873143002
Cr-Commit-Position: refs/heads/master@{#26270}
Notes:
- All the added authors have signed the CLA.
- Updated 2 AUTHORS lines to match the e-mail addresses used for signing the CLA.
- In addition, checked that all authors in the AUTHORS file after this change
have signed the CLA.
- Whenever it was possible to guess, based on the e-mail address, that the
contribution was made under a corporate CLA, added the company and the
wildcard instead of the individual.
BUG=
NOTRY=true
Review URL: https://codereview.chromium.org/832083004
Cr-Commit-Position: refs/heads/master@{#26054}
Updating AUTHORS for companies who have signed CCLA.
Changes:
- Added wildcard rules for company e-mail addresses
- Removed individual e-mail addresses for contributors who are under a corporate
CLLA (the copyright holder in this case is the company, not the individual
authors). Domains affected by this change: intel.com, arm.com, codeaurora.org.
In addition, added a wildcard rule for Chromium (which was not previously
listed at all).
R=danno
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/850653003
Cr-Commit-Position: refs/heads/master@{#26039}
