- 25 Jan, 2017 10 commits
-
-
mstarzinger authored
This fixes the checks of accumulator usage flags in the computation of the interpreter register liveness during bytecode analysis. The usage flags at hand are bit patterns as opposed to flat enum values. Use the safe accessors instead of plain comparison. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-683581 BUG=chromium:683581 Review-Url: https://codereview.chromium.org/2651653005 Cr-Commit-Position: refs/heads/master@{#42648}
-
bmeurer authored
This adds support to constant-fold JSGetSuperConstructor(constructor) for constructors with stable maps, i.e. where we can add a stability dependency on the constructors map to get notified when the [[Prototype]] of constructor changes. R=petermarshall@chromium.org BUG=v8:5517 Review-Url: https://codereview.chromium.org/2652763010 Cr-Commit-Position: refs/heads/master@{#42647}
-
jgruber authored
This test checks that counters accurately reflect the allocated size. There's an edge case that can occur when, previously to the allocation, the page does not have enough space left to allocate the requested object - then we move on to a fresh page, fill the remaining space of the old page with a filler object, and allocate the requested object on the new page. The counters will show the size of the filler object plus the requested object size, while the test expects only the requested size. This CL fixes that case by performing two GCs to clear out new space. BUG= Review-Url: https://codereview.chromium.org/2652933002 Cr-Commit-Position: refs/heads/master@{#42646}
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2653693003 Cr-Commit-Position: refs/heads/master@{#42645}
-
kozyatinskiy authored
- kDebugPromiseCreated(task, parent_task) This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map. - kDebugEnqueueAsyncFunction(task) This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point. - kDebugEnqueuePromiseResolve(task), This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point. - kDebugEnqueuePromiseReject(task), This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point. - kDebugPromiseCollected, This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise. - kDebugWillHandle, This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise. - kDebugDidHandle, This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one. With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task). Before V8Debugger supported only the following: - asyncTaskScheduled(task1) - asyncTaskStarted(task1) - asyncTaskFinished(task1) Now V8Debugger supports the following: - asyncTaskScheduled(parent_task) .. - asyncTaskCreated(task, parent_task), - asyncTaskStarted(task), uses parent_task scheduled stack - asyncTaskScheduled(task) - asyncTaskFinished(task) Additionally: WillHandle and DidHandle were migrated to PromiseHook API. More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2650803003 Cr-Commit-Position: refs/heads/master@{#42644}
-
bmeurer authored
In the JSCallReducer we'd inline certain builtins like the Array constructor or Function builtins across native contexts, which at this point should be mostly safe, but might lead to cross context leaks in the future (as it's not obvious that the JSCallReducer) doesn't maintain this invariant. So better safe than sorry. R=yangguo@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2651133002 Cr-Commit-Position: refs/heads/master@{#42643}
-
zhengxing.li authored
port f9367847 (r42632) original commit message: We can share almost all of the architecture-specific builtin code with super-call-with-spread. Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store. BUG= Review-Url: https://codereview.chromium.org/2652153002 Cr-Commit-Position: refs/heads/master@{#42642}
-
zhengxing.li authored
port d287c819 (r42620) original commit message: [RELAND with one change: until literal arrays are rooted in the outer feedback vector (coming in the next days), the runtime-scope.cc change is held off.] When a function is declared in global scope, the closure is created by the DeclareGlobals runtime service. It needs a pointer to the literals array, already allocated in the feedback vector. This fixes a bug where it's behavior wasn't in sync with CreateClosure, which accepts the literals from the vector. This enables a follow-on performance improvement in the CompileLazy builtin. BUG= Review-Url: https://codereview.chromium.org/2653893002 Cr-Commit-Position: refs/heads/master@{#42641}
-
cbruni authored
Array.prototype.concat does not properly handle JSProxy species that will modify the currently visited array. BUG=682194 Review-Url: https://codereview.chromium.org/2655623004 Cr-Commit-Position: refs/heads/master@{#42640}
-
brettw authored
We're converting the build_overrides system to the new default_args list of overrides that can be listed in the toplevel .gn file. This will allow args to be set on a per-repo basis. This change conditionally adds the variables currently defined in build_overrides/v8.gni to build args. This allows V8's build to be used in both the new and old systems. Once all Chrome and pdfium have been updated, v8's build overrides and the conditional checks around the new args can be removed. BUG=684096 Review-Url: https://codereview.chromium.org/2654663003 Cr-Commit-Position: refs/heads/master@{#42639}
-
- 24 Jan, 2017 26 commits
-
-
leszeks authored
Since JumpLoop is always backwards, and other jumps are always forwards, we can store the jump offset as an always positive integer and decide on the jump direction based on the bytecode. This will save a small amount of space for large-ish for loops (>128 bytecodes). Review-Url: https://codereview.chromium.org/2641443002 Cr-Commit-Position: refs/heads/master@{#42638}
-
franzih authored
The property backing store size depends on the number of index keys. Pass index keys to the factory function instead calculating the size outside. R=verwaest@chromium.org BUG=v8:5625 Review-Url: https://codereview.chromium.org/2651533002 Cr-Commit-Position: refs/heads/master@{#42637}
-
mtrofin authored
BUG=v8:5885 Review-Url: https://codereview.chromium.org/2649163004 Cr-Commit-Position: refs/heads/master@{#42636}
-
gsathya authored
BUG=v8:5549 Review-Url: https://codereview.chromium.org/2653643004 Cr-Commit-Position: refs/heads/master@{#42635}
-
titzer authored
R=ahaas@chromium.org,rossberg@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2626263004 Cr-Commit-Position: refs/heads/master@{#42634}
-
rmcilroy authored
Speculative reason for issue 684481. BUG=chromium:684481 TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org, Original issue's description: > [Parse] ParseInfo owns the parsing Zone. > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > in preperation for enabling background compilation jobs for inner functions > share the AST in the outer-function's parse zone memory (read-only), with the > and zone being released when all compilation jobs have completed. > > BUG=v8:5203, v8:5215 > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Commit-Position: refs/heads/master@{#42562} > Committed: https://chromium.googlesource.com/v8/v8/+/4b0101d369af121a6daf5e5c731cb939c026d526 Review-Url: https://codereview.chromium.org/2648383005 Cr-Commit-Position: refs/heads/master@{#42633}
-
petermarshall authored
We can share almost all of the architecture-specific builtin code with super-call-with-spread. Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2649143002 Cr-Commit-Position: refs/heads/master@{#42632}
-
marja authored
Using a Handle<Foo> as a member doesn't require including foo.h R=mstarzinger@chromium.org BUG=v8:5402 Review-Url: https://codereview.chromium.org/2650973003 Cr-Commit-Position: refs/heads/master@{#42631}
-
tebbi authored
R=mstarzinger@chromium.org, bmeurer@chromium.org BUG=chromium:669242 Review-Url: https://codereview.chromium.org/2645273003 Cr-Commit-Position: refs/heads/master@{#42630}
-
titzer authored
R=ahaas@chromium.org BUG=v8:5882 Review-Url: https://codereview.chromium.org/2657463003 Cr-Commit-Position: refs/heads/master@{#42629}
-
mlippautz authored
BUG=chromium:679724 Review-Url: https://codereview.chromium.org/2627033002 Cr-Commit-Position: refs/heads/master@{#42628}
-
marja authored
It was a scary function which handled all possible old-fashioned and for-each statements at one go. Split it to multiple smaller functions and made the top level logic clearer. BUG= Review-Url: https://codereview.chromium.org/2645353002 Cr-Commit-Position: refs/heads/master@{#42627}
-
machenbach authored
This disables optimizations when using typed float arrays in correctness fuzzer test cases. Otherwise, different NaN patterns in float typed arrays might lead to different observations when using the buffer in an int array view. BUG=chromium:683579 NOTRY=true TBR=Jarin, mvstanton, Igor Sheludko Review-Url: https://codereview.chromium.org/2649923008 Cr-Commit-Position: refs/heads/master@{#42626}
-
marja authored
The "sloppy eval in default param" cases will be useful for the future tests which assert that parser and preparser produce the same scopes. BUG=v8:5501, v8:5516 Review-Url: https://codereview.chromium.org/2644333002 Cr-Commit-Position: refs/heads/master@{#42625}
-
clemensh authored
Implement stepping by remembering the current step action in the wasm interpreter handle in WasmDebugInfo, and using it when continuing execution in the interpreter. The control flow is as follows: After module compilation, the user sets a breakpoint in wasm. The respective function is redirected to the interpreter and the breakpoint is set on the interpreter. When it is hit, we notify all debug event listeners, which might prepare stepping. When returning from these listeners, before continuing execution, we check whether stepping was requested and continue execution in the interpreter accordingly. Stepping from Wasm to JS and vice versa will be implemented and tested in a follow-up CL. Testing this requires breakpoints and stepping in Wasm to be exposed via the inspector interface, such that we can write an inspector test. This mixed JS-Wasm-execution is hard to set up in a cctest. R=titzer@chromium.org, yangguo@chromium.org BUG= Review-Url: https://codereview.chromium.org/2649533002 Cr-Commit-Position: refs/heads/master@{#42624}
-
ahaas authored
Similar to the maximum memory size this limit caused problems for the fuzzer due to oom issues. With the command line flag we can limit the maximum table size for the fuzzer. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2648223004 Cr-Commit-Position: refs/heads/master@{#42623}
-
titzer authored
BUG=v8:5860 R=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2653533003 Cr-Commit-Position: refs/heads/master@{#42622}
-
jarin authored
BUG=chromium:678917 Review-Url: https://codereview.chromium.org/2653623002 Cr-Commit-Position: refs/heads/master@{#42621}
-
mvstanton authored
[RELAND with one change: until literal arrays are rooted in the outer feedback vector (coming in the next days), the runtime-scope.cc change is held off.] When a function is declared in global scope, the closure is created by the DeclareGlobals runtime service. It needs a pointer to the literals array, already allocated in the feedback vector. This fixes a bug where it's behavior wasn't in sync with CreateClosure, which accepts the literals from the vector. This enables a follow-on performance improvement in the CompileLazy builtin. BUG=680637 Review-Url: https://codereview.chromium.org/2634283003 Cr-Commit-Position: refs/heads/master@{#42620}
-
machenbach authored
BUG=chromium:683494 NOTRY=true TBR=yangguo@chromium.org, jarin@chromium.org Review-Url: https://codereview.chromium.org/2651713005 Cr-Commit-Position: refs/heads/master@{#42619}
-
mtrofin authored
Chromium coding standard (https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#Multiple-inheritance) In this case, a structure associating the 2 values is sufficient. BUG= Review-Url: https://codereview.chromium.org/2651903002 Cr-Commit-Position: refs/heads/master@{#42618}
-
zhengxing.li authored
port 3a9152ec (r42594) original commit message: We are planning to add a few more debugger related bits, and are running out of compiler hints bits. The new bit field is going to be part of the debug info struct. If the debug info is not available, we store the bit field in its place on the shared function info. BUG= Review-Url: https://codereview.chromium.org/2649893004 Cr-Commit-Position: refs/heads/master@{#42617}
-
bradnelson authored
A recent change to disallow wasm compilation in contexts where CSP unsafe-eval would disallow eval also ended up banning asm.js there: https://codereview.chromium.org/2646713002 This ends up banning non-evaled asm.js even in some places it should be allowed. NOTE: Although asm.js code converted to wasm generates an intermediate wasm module. asm.js code evaled in a disallowed context can't even get that far (as it's stoped at the eval site). BUG=683867 R=mtrofin@chromium.org,titzer@chromium.org,adamk@chromium.org Review-Url: https://codereview.chromium.org/2656463004 Cr-Commit-Position: refs/heads/master@{#42616}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0081085..dbe38ca Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/cb12d6e..8e94621 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/49e3f62..e1e778d Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fa8cd67..58fecbe TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2649983004 Cr-Commit-Position: refs/heads/master@{#42615}
-
kozyatinskiy authored
V8 has internal mechanism to ignore steps and breaks inside internal scripts, in this CL it's reused for blackboxing implementation. Advantages: - much faster blackboxing implementation (before we at least wrap and collect current call stack for each step), - get rid of StepFrame action and potential pause in blackboxed code after N StepFrame steps, - simplification of debugger agent logic. Disadvtanges: - currently when user was paused in blackboxed code (e.g. on breakpoint) and then makes step action, debugger ignores blackboxed state of the script and allows to use step actions as usual - this behavior is regressed, we still able to support it on frontend side. Current state and proposed changes for blackboxing: https://docs.google.com/document/d/1hnzaXPAN8_QC5ENxIgxgMNDbXLraM_OXT73rAyijTF8/edit?usp=sharing BUG=v8:5842 R=yangguo@chromium.org,dgozman@chromium.org,alph@chromium.org Review-Url: https://codereview.chromium.org/2633803002 Cr-Commit-Position: refs/heads/master@{#42614}
-
gsathya authored
Check that number of properties < Code:kMaxArguments when object destructuring with a rest property otherwise throw an error. BUG=v8:5549 Review-Url: https://codereview.chromium.org/2650863002 Cr-Commit-Position: refs/heads/master@{#42613}
-
- 23 Jan, 2017 4 commits
-
-
mattloring authored
Also introduces FFIType separate from MachineType for express ffi signatures. BUG=v8:4456 Review-Url: https://codereview.chromium.org/2639163004 Cr-Commit-Position: refs/heads/master@{#42612}
-
binji authored
Atomics.wait is a function which may block, which is not allowed on the main thread. Since V8 doesn't know whether a particular isolate is the "main thread", this CL adds an option to Isolate::CreateParams to choose whether this function is allowed. Review-Url: https://codereview.chromium.org/2642293002 Cr-Commit-Position: refs/heads/master@{#42611}
-
bbudge authored
LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2629223005 Cr-Commit-Position: refs/heads/master@{#42610}
-
ishell authored
Manipulating the signaling NaN used for the hole and uninitialized double field sentinel in C++, e.g. with bit_cast or HeapNumber::value()/set_value(), will change its value on ia32 (the x87 stack is used to return values and stores to the stack silently clear the signalling bit). BUG=v8:5495 Review-Url: https://codereview.chromium.org/2652553003 Cr-Commit-Position: refs/heads/master@{#42609}
-