Skip to content

V
V8
Switch branch/tag
  1. 10 Mar, 2017 1 commit
  3. 09 Mar, 2017 1 commit
  5. 01 Mar, 2017 2 commits
    • bmeurer's avatar
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of... · 0b3e554e
      bmeurer authored 
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ )

Reason for revert:
Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory

Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43523}
> Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a

TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2723133003
Cr-Commit-Position: refs/heads/master@{#43525}
      0b3e554e
    • eholk's avatar
      [wasm] Initial signal handler · a5af7fe9
      eholk authored 
      This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43523}
      a5af7fe9
  7. 23 Feb, 2017 1 commit
  9. 21 Feb, 2017 1 commit
    • mtrofin's avatar
      [wasm] Managed<T> ensures T's lifetime does not leak past Isolate's · caa1d4b2
      mtrofin authored 
      Native resources allocated by v8, as internal implementation detail,
and held by a Foreign object, must be released when the Isolate is
torn down. Example: wasm::WasmModule allocated by wasm compile, and
held throughout the lifetime of the WebAssembly.Module object.

This change:
- Extends Managed<CppType> with a mechanism for doing just that
- Separates the role of Managed<CppType> to be strictly an owner of
the lifetime of the native resource. For cases where that's not
desirable, we can polymorphically use Foregin.
- moves managed.h out of wasm, since it's not wasm-specific.

BUG=680065

Review-Url: https://codereview.chromium.org/2676513008
Cr-Commit-Position: refs/heads/master@{#43350}
      caa1d4b2
  11. 13 Feb, 2017 2 commits
    • bmeurer's avatar
      [es2015] Remove the @@hasInstance protector cell. · 1a236208
      bmeurer authored 
      We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.

R=yangguo@chromium.org
TBR=ulan@chromium.org
BUG=v8:5958

Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
      1a236208
    • gsathya's avatar
      [promises] cleanup default promise handlers · 31bc17f0
      gsathya authored 
      Use private symbols to mark default promise handler, instead of calling out to default
handlers defined in JS. We check for this symbol in PromiseHandle and perform the
appropriate behavior as the default handlers.

Catch prediction logic is updated to account for a symbol.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2695593002
Cr-Commit-Position: refs/heads/master@{#43135}
      31bc17f0
  13. 10 Feb, 2017 3 commits
  15. 08 Feb, 2017 2 commits
  17. 30 Jan, 2017 2 commits
  19. 25 Jan, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] change target promise for kDebugWillHandle & kDebugDidHandle · cb545a8c
      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}
      cb545a8c
  21. 17 Jan, 2017 2 commits
  23. 16 Jan, 2017 2 commits
  25. 13 Jan, 2017 3 commits
  27. 12 Jan, 2017 2 commits
    • gsathya's avatar
      [promisehook] Pass deferred promise to Before/After callback · 687b60c8
      gsathya authored 
      Before, in `var p1 = p.then(() => {}) we would trigger the
before/after callbacks with p as the associated promise, but we must
call it with p1.

Also removes promise from PromiseReactionJobInfo.

Review-Url: https://codereview.chromium.org/2633443002
Cr-Commit-Position: refs/heads/master@{#42295}
      687b60c8
    • clemensh's avatar
      Refactor FrameSummary for JS and Wasm frames · df5417ae
      clemensh authored 
      Wasm frames can be either compiled or interpreted. For interpreted wasm
frames, there is only one physical stack frame representing an
arbitrary stack of interpreted functions. Hence the physical stack
frame needs to provide a summary of the underlying functions.
Summaries were tailored for JavaScript frames before. Now they are
universal.

The refactored FrameSummaries are now also used in the FrameInspector,
and from the StackFrame objects themselves, to avoid code duplication.

All dispatch is implemented "manually", making the FrameSummary still
stack-allocatable.

BUG=v8:5822
R=yangguo@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2619353006
Cr-Commit-Position: refs/heads/master@{#42279}
      df5417ae
  29. 11 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmToInterpreterFrame · 81700ddf
      clemensh authored 
      and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.

R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
      81700ddf
  31. 10 Jan, 2017 1 commit
  33. 03 Jan, 2017 1 commit
    • gsathya's avatar
      [promises] Refactor debug code · a2c15ba3
      gsathya authored 
      -- Removes remaning debug from promise.js and moves it to c++
-- Changes debug_id to be a smi in PromiseReactionJobInfo and
   PromiseResolveThenableJobInfo.
-- Changes debug_name to be a smi in PromiseReactionJobInfo and
   PromiseResolveThenableJobInfo.
-- Adds PromiseDebugActionName and PromiseDebugActionType enums
-- Adds PromiseDebugActionNameToString and
   PromiseDebugActionTypeToString helper methods
-- Changes variable `status` to be int in runtime functions.
-- Changes debug_id to start from 1, not 0 for easier bookkeeping.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2606093002
Cr-Commit-Position: refs/heads/master@{#42052}
      a2c15ba3
  35. 29 Dec, 2016 1 commit
    • gsathya's avatar
      [promises] Remove deferred object · 5668ce39
      gsathya authored 
      This patch stores the promise, resolve, reject properties of the
deferred object created by CreateInternalPromiseCapability and
NewPromiseCapability directly on the promise (if the promise hasn't
been fulfilled), otherwise they are stored on the
PromiseReactionJobInfo.

This patch removes the currently unused
CreateInternalPromiseCapability and inlines the call to create the
deferred promise object.

NewPromiseCapability is the only function that works with a deferred.

This patch results in a 8.5% improvement in benchmarks over 5 runs.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2590563003
Cr-Commit-Position: refs/heads/master@{#41991}
      5668ce39
  37. 23 Dec, 2016 2 commits
  39. 20 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmSharedModuleData and refactor other objects · 081ac370
      clemensh authored 
      The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.

While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732

Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}
      081ac370
  41. 19 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      clemensh authored 
      When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.

R=titzer@chromium.org
CC=jgruber@chromium.org
BUG=v8:5620

Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}
      21a85c4a
  43. 16 Dec, 2016 3 commits
  45. 15 Dec, 2016 1 commit
  47. 13 Dec, 2016 1 commit
    • gsathya's avatar
      PromiseHandle port to TF · 9fc3c017
      gsathya authored 
      Splits PromiseHandle into two TF builtins to account for catch
prediction. An exception in PromiseHandleReject builtin results in a
"caught" prediction whereas an expception in PromiseHandle results in a
"promise rejection" prediction.

An extra is_exception_caught bit is added to Code to mark this catch
prediction behavior.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2572623002
Cr-Commit-Position: refs/heads/master@{#41683}
      9fc3c017
  49. 12 Dec, 2016 2 commits