- 13 Dec, 2016 4 commits
-
-
gsathya authored
Review-Url: https://codereview.chromium.org/2569663003 Cr-Commit-Position: refs/heads/master@{#41662}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7321edc..52f7afe Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/19565fd..c69690a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/53bdedc..7e13606 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2566153004 Cr-Commit-Position: refs/heads/master@{#41661}
-
gsathya authored
BUG=v8:5343 Review-Url: https://codereview.chromium.org/2571663002 Cr-Commit-Position: refs/heads/master@{#41660}
-
zhengxing.li authored
Currently the jump label's distance value in LCodeGen::DoWrapReceiver() of X86 is unconsistent. For avoiding potential bugs caused by this unconsistent usage for the same label when DeoptEveryNTimes() return true, This CL unify the label's distance value usage in LCodeGen::DoWrapReceiver(). For more informations, please refer CL #41419 (https://codereview.chromium.org/2539403002/ ). BUG= Review-Url: https://codereview.chromium.org/2554493002 Cr-Commit-Position: refs/heads/master@{#41659}
-
- 12 Dec, 2016 28 commits
-
-
lpy authored
When ParseOnBackground is done, we should construct a trace event and dump all background parsing runtime statistics as argument. In tracing we don't want to merge it back to to main thread, instead we show the trace event together with background parsing trace event on script streamer thread track in Trace Viewer. To perf sheriff: A series of counters ParseBackgroundxxx and PreparseBackgroundxxx will be taken into account in this patch, thus runtime statistics graph will increase after this patch gets landed. BUG=v8:5089 Review-Url: https://codereview.chromium.org/2559403002 Cr-Commit-Position: refs/heads/master@{#41658}
-
dgozman authored
This is to improve the performance of common operation of extracting contextId or contextGroupId out of Context. BUG=none Review-Url: https://codereview.chromium.org/2558913004 Cr-Commit-Position: refs/heads/master@{#41657}
-
jkummerow authored
...and HasProperty, for dictionary-elements receivers. BUG=chromium:673008 Review-Url: https://codereview.chromium.org/2568943002 Cr-Commit-Position: refs/heads/master@{#41656}
-
hpayer authored
BUG=chromium:630386 Review-Url: https://codereview.chromium.org/2440943002 Cr-Commit-Position: refs/heads/master@{#41655}
-
hpayer authored
BUG= Review-Url: https://codereview.chromium.org/2566133002 Cr-Commit-Position: refs/heads/master@{#41654}
-
ishell authored
BUG= Review-Url: https://codereview.chromium.org/2568173002 Cr-Commit-Position: refs/heads/master@{#41653}
-
titzer authored
R=bradnelson@chromium.org,ishell@chromium.org BUG= Review-Url: https://codereview.chromium.org/2570543002 Cr-Commit-Position: refs/heads/master@{#41652}
-
ishell authored
BUG= Review-Url: https://codereview.chromium.org/2568713002 Cr-Commit-Position: refs/heads/master@{#41651}
-
jochen authored
It doesn't schedule steps yet, but there are tests. BUG=v8:5215 R=rmcilroy@chromium.org,marja@chromium.org Review-Url: https://codereview.chromium.org/2558293004 Cr-Commit-Position: refs/heads/master@{#41650}
-
ishell authored
All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
-
bradnelson authored
Generalize Messages to include an error level. Add a parameter to AddMessageHandler to select which error levels to receive, using a mask (default being just errors, i.e. the current behavior). BUG=v8:4203 R=dgozman@chromium.org,machenbach@chromium.org,danno@chromium.org,bmeurer@chromium.org,jochen@chromium.org Review-Url: https://codereview.chromium.org/2526703002 Cr-Commit-Position: refs/heads/master@{#41648}
-
bradnelson authored
BUG=672789 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2559113006 Cr-Commit-Position: refs/heads/master@{#41647}
-
hpayer authored
BUG= Review-Url: https://codereview.chromium.org/2562383002 Cr-Commit-Position: refs/heads/master@{#41646}
-
marja authored
BUG=v8:5501, v8:5678 Review-Url: https://codereview.chromium.org/2539123002 Cr-Commit-Position: refs/heads/master@{#41645}
-
hablich authored
Revert of [heap] Initialize the owner on each page after lospace allocation (patchset #2 id:20001 of https://codereview.chromium.org/2565713002/ ) Reason for revert: Tree closer: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/12409 Original issue's description: > [heap] Initialize the owner on each page after lospace allocation > > The least two bits of the owner field of a Page are used to determine > whether the Page is part of a large object. If these bits are not equal > to 0x11, the page is part of a large object and needs special handling > e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it > belongs to. > > This CL fixes an issue in which the store buffer overflows after > a large object space allocation but before the object has been fully > initialized. Store buffer overflow handling attempts to look up the > chunk of a page, but fails to do so correctly since the page's owner > field has not yet been initialized. > > This CL ensures that the owner field of all pages belonging to a large > object allocation are initialized to a value that is interpreted > correctly. > > BUG=chromium:672041 > > Committed: https://crrev.com/9b6808bfb5366beebe3af30a06f9851edb2039d4 > Cr-Commit-Position: refs/heads/master@{#41641} TBR=mlippautz@chromium.org,jgruber@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:672041 Review-Url: https://codereview.chromium.org/2562273004 Cr-Commit-Position: refs/heads/master@{#41644}
-
bradnelson authored
BUG=673240 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2565343002 Cr-Commit-Position: refs/heads/master@{#41643}
-
clemensh authored
This CL moves all methods related to scripts and eval origin (HasScript, GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase, because it also applies to WasmFrames. This makes the AppendFileLocation method append the same information to WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames. R=titzer@chromium.org, mstarzinger@chromium.org BUG=v8:4203 Review-Url: https://codereview.chromium.org/2557923005 Cr-Commit-Position: refs/heads/master@{#41642}
-
jgruber authored
The least two bits of the owner field of a Page are used to determine whether the Page is part of a large object. If these bits are not equal to 0x11, the page is part of a large object and needs special handling e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it belongs to. This CL fixes an issue in which the store buffer overflows after a large object space allocation but before the object has been fully initialized. Store buffer overflow handling attempts to look up the chunk of a page, but fails to do so correctly since the page's owner field has not yet been initialized. This CL ensures that the owner field of all pages belonging to a large object allocation are initialized to a value that is interpreted correctly. BUG=chromium:672041 Review-Url: https://codereview.chromium.org/2565713002 Cr-Commit-Position: refs/heads/master@{#41641}
-
clemensh authored
The current logic in Isolate::GetLocationFromStackTrace just ignores wasm frames, making the computed location point to the first javascript frame, like this: test.js:17: RuntimeError: divide by zero module.exports.main(); ^ RuntimeError: divide by zero at main (<WASM>[1]+5) at test.js:17:16 This CL not only fixes the location to point to the top-most wasm frame, but also exposes to the embedder that the script of that location is a wasm script, allowing for custom printing of wasm locations. The Shell::ReportException method now checks for this flag, and prints wasm locations like this: <WASM>[0]+5: RuntimeError: divide by zero RuntimeError: divide by zero at main (<WASM>[0]+5) at test/message/wasm-trap.js:15:16 R=titzer@chromium.org, yangguo@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2563673002 Cr-Commit-Position: refs/heads/master@{#41640}
-
clemensh authored
This only happens if there is a asm.js-wasm-frame on top of the stack trace, which was not covered by our tests so far. The regression test create a stack overflow in asm.js code, triggering this case. R=mstarzinger@chromium.org CC=titzer@chromium.org, bradnelson@chromium.org BUG=chromium:673241 Review-Url: https://codereview.chromium.org/2562333002 Cr-Commit-Position: refs/heads/master@{#41639}
-
bradnelson authored
BUG=673240 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2568773002 Cr-Commit-Position: refs/heads/master@{#41638}
-
danno authored
Review-Url: https://codereview.chromium.org/2558283002 Cr-Commit-Position: refs/heads/master@{#41637}
-
petermarshall authored
Add the operator in preparation for actual perf work. The operator is replaced by the same runtime call as before, during lowering. The CallConstructWithSpreadParameters is a bit silly at the moment, but will hold more once we add feedback. BUG=v8:5659 Review-Url: https://codereview.chromium.org/2561103003 Cr-Commit-Position: refs/heads/master@{#41636}
-
neis authored
For generator-based functions (e.g. async functions) we force variables to be context-allocated. Due to a bug in the parser, this didn't always work correctly. For instance, in "async function foo([a]) { ... }" the variable "a" could become stack-allocated due to context allocation being forced on the wrong scope. Besides fixing this, I'm also cleaning up some related code in the async parsing setup and adding some guards. R=adamk@chromium.org, littledan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2561093002 Cr-Commit-Position: refs/heads/master@{#41635}
-
jarin authored
BUG=chromium:673244 Review-Url: https://codereview.chromium.org/2568053002 Cr-Commit-Position: refs/heads/master@{#41634}
-
petermarshall authored
The evaluation order of this argument was accidentally changed when the special-case was added for super calls with a final spread argument. Review-Url: https://codereview.chromium.org/2563423002 Cr-Commit-Position: refs/heads/master@{#41633}
-
jarin authored
Review-Url: https://codereview.chromium.org/2566933002 Cr-Commit-Position: refs/heads/master@{#41632}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/15a6efa..7321edc Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/dda089a..73e2473 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2569653002 Cr-Commit-Position: refs/heads/master@{#41631}
-
- 11 Dec, 2016 2 commits
-
-
franzih authored
BUG= Review-Url: https://codereview.chromium.org/2565093003 Cr-Commit-Position: refs/heads/master@{#41630}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ca0069e..15a6efa Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/707aaac..19565fd TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2562213002 Cr-Commit-Position: refs/heads/master@{#41629}
-
- 10 Dec, 2016 3 commits
-
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/50196c9..ca0069e Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/0b7222f..707aaac TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2560373002 Cr-Commit-Position: refs/heads/master@{#41628}
-
gsathya authored
--asan test config passes --omit-quit which breaks this test on failure. Review-Url: https://codereview.chromium.org/2546093002 Cr-Commit-Position: refs/heads/master@{#41627}
-
bjaideep authored
Port d4f01b8a Original Commit Message: Add fast paths for holey smi and object arrays to Function.prototype.apply, Reflect.apply and Reflect.construct. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2566793002 Cr-Commit-Position: refs/heads/master@{#41626}
-
- 09 Dec, 2016 3 commits
-
-
ulan authored
Forcing finalization after reaching allocation limit regresses gc pause time in benchmarks as we have to do a lot of non-incremental marking work. This patch allows overshoot of the limit by some margin. BUG=chromium:670675,chromium:671994 TBR=mlippautz@chromium.org Review-Url: https://codereview.chromium.org/2554423005 Cr-Commit-Position: refs/heads/master@{#41625}
-
bradnelson authored
BUG=672785 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2566683002 Cr-Commit-Position: refs/heads/master@{#41624}
-
mstarzinger authored
This fixes the corner-case where the method in question failed to lookup the very last deoptimization bailout without subsequent entries within the relocation info. Also enable a test covering this. R=tebbi@chromium.org TEST=cctest/test-cpu-profiler/CollectDeoptEvents Review-Url: https://codereview.chromium.org/2565733002 Cr-Commit-Position: refs/heads/master@{#41623}
-