The code in `AsmJsScanner::Next()` checks for both
end of input and parse error:
if (token_ == kEndOfInput || token_ == kParseError) {
return;
}
but until now the code in the parsing loop only checked
for `kEndOfInput`, resulting in an infinite loop on
`kParseError`.
R=bradnelson@chromium.org, mstarzinger@chromium.org
Bug: chromium:771428
Change-Id: I9170f090503590b3b9b949a0d00ab4daef85bf66
Reviewed-on: https://chromium-review.googlesource.com/699994
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48290}
Formerly known as Opera TV.
Change-Id: If141d86e744f3ea9dc9605f6d2b35fc78d291a69
Reviewed-on: https://chromium-review.googlesource.com/683175
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48212}
As part of J2V8 development (https://github.com/eclipsesource/J2V8),
we realized that we had a subtle bug in how Isolate scope was created
and it's lifetime managed, see:
https://github.com/eclipsesource/J2V8/issues/313.
Mentioned above bug was fixed, however, what we also noticed is that
V8 API has been constantly and slowly moving to such an API, in which
one has to pass Isolate explicitly to methods and/or constructors. We
found two more places that might have been overlooked. This contribution
adds passing of Isolate pointer explicitly to constructors of
String::Utf8Value and String::Value classes.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I61984285f152aba5ca922100cf3df913a9cb2cea
Reviewed-on: https://chromium-review.googlesource.com/593309
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47656}
- Convert S.p.includes builtin from CPP to TFJ
- Fast paths S.p.includes(str) and S.p.includes(str, smi)
- Add Runtime kStringIncludes
- Add StringIncludesIndexOfAssembler (Generate is based on
StringPrototypeIndexOf builtin)
- S.p.includes and S.p.indexOf both use StringIncludesIndexOfAssembler
Quick measurements show 3x improvement for S.p.includes(str).
More about the measurements: https://gist.github.com/peterwmwong/7a2a96f3171a52f16ca8125a089f38e7
Bug: v8:6680
Change-Id: I79cb8dbe2b79e6df15aa734e128eee25c7e6aaf5
Reviewed-on: https://chromium-review.googlesource.com/620150
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47546}
We are unblocking contributors from @fb.com and @oculus.com to contribute to Chromium. Our primary contributor group is still specified in our Facebook CLA group and should be consulted before allowing any contributions.
Bug:
Change-Id: I21ee84a29382f034184d053b77b02c78e6055791
Reviewed-on: https://chromium-review.googlesource.com/558708
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46997}
Building on Windows with gyp fails depending on the result from
sharding the src/v8.gyp:v8_base target. If two source files with the
same name are in the same shard, their output object file path would
conflict with one another. One example of this conflict is v8_base's
runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
is generated at build time, for which the files runtime.obj and
Runtime.obj would be created, but MSVS overwrites one of them with
the other.
Dividing the .obj output path by the original source's extension
prevents this overwrite.
Refs: https://github.com/nodejs/node/pull/13959
Bug:
Change-Id: I158e6178f2511297899ee50ea159f574916f903f
Reviewed-on: https://chromium-review.googlesource.com/556599
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46354}
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}
