Skip to content

Commit

Permalink
upgrade V8 to v8.0.426.15 (#29)
Browse files Browse the repository at this point in the history
  • Loading branch information
rogchap authored Jan 25, 2020
1 parent bce58ca commit 8dbccdc
Show file tree
Hide file tree
Showing 21 changed files with 5,061 additions and 421 deletions.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ GoDoc: https://godoc.org/rogchap.com/v8go

## V8 dependency

V8 version: 7.7.299.9
V8 version: 8.0.426.15

In order to make `v8go` usable as a standard Go package, prebuilt static libraries of V8
are included for Linux and OSX ie. you *should not* require to build V8 yourself.
Expand Down
Binary file modified deps/darwin-x86_64/libv8.a
Binary file not shown.
2 changes: 1 addition & 1 deletion deps/depot_tools
Submodule depot_tools updated from 82ae4b to 0aa48c
72 changes: 72 additions & 0 deletions deps/include/APIDesign.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# The V8 public C++ API

# Overview

The V8 public C++ API aims to support four use cases:

1. Enable applications that embed V8 (called the embedder) to configure and run
one or more instances of V8.
2. Expose ECMAScript-like capabilities to the embedder.
3. Enable the embedder to interact with ECMAScript by exposing API objects.
4. Provide access to the V8 debugger (inspector).

# Configuring and running an instance of V8

V8 requires access to certain OS-level primitives such as the ability to
schedule work on threads, or allocate memory.

The embedder can define how to access those primitives via the v8::Platform
interface. While V8 bundles a basic implementation, embedders are highly
encouraged to implement v8::Platform themselves.

Currently, the v8::ArrayBuffer::Allocator is passed to the v8::Isolate factory
method, however, conceptually it should also be part of the v8::Platform since
all instances of V8 should share one allocator.

Once the v8::Platform is configured, an v8::Isolate can be created. All
further interactions with V8 should explicitly reference the v8::Isolate they
refer to. All API methods should eventually take an v8::Isolate parameter.

When a given instance of V8 is no longer needed, it can be destroyed by
disposing the respective v8::Isolate. If the embedder wishes to free all memory
associated with the v8::Isolate, it has to first clear all global handles
associated with that v8::Isolate.

# ECMAScript-like capabilities

In general, the C++ API shouldn't enable capabilities that aren't available to
scripts running in V8. Experience has shown that it's not possible to maintain
such API methods in the long term. However, capabilities also available to
scripts, i.e., ones that are defined in the ECMAScript standard are there to
stay, and we can safely expose them to embedders.

The C++ API should also be pleasant to use, and not require learning new
paradigms. Similarly to how the API exposed to scripts aims to provide good
ergonomics, we should aim to provide a reasonable developer experience for this
API surface.

ECMAScript makes heavy use of exceptions, however, V8's C++ code doesn't use
C++ exceptions. Therefore, all API methods that can throw exceptions should
indicate so by returning a v8::Maybe<> or v8::MaybeLocal<> result,
and by taking a v8::Local<v8::Context> parameter that indicates in which
context a possible exception should be thrown.

# API objects

V8 allows embedders to define special objects that expose additional
capabilities and APIs to scripts. The most prominent example is exposing the
HTML DOM in Blink. Other examples are e.g. node.js. It is less clear what kind
of capabilities we want to expose via this API surface. As a rule of thumb, we
want to expose operations as defined in the WebIDL and HTML spec: we
assume that those requirements are somewhat stable, and that they are a
superset of the requirements of other embedders including node.js.

Ideally, the API surfaces defined in those specs hook into the ECMAScript spec
which in turn guarantees long-term stability of the API.

# The V8 inspector

All debugging capabilities of V8 should be exposed via the inspector protocol.
The exception to this are profiling features exposed via v8-profiler.h.
Changes to the inspector protocol need to ensure backwards compatibility and
commitment to maintain.
4 changes: 4 additions & 0 deletions deps/include/DEPS
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
include_rules = [
# v8-inspector-protocol.h depends on generated files under include/inspector.
"+inspector",
]
18 changes: 18 additions & 0 deletions deps/include/OWNERS
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

per-file *DEPS=file:../COMMON_OWNERS
per-file v8-internal.h=file:../COMMON_OWNERS
per-file [email protected]
per-file [email protected]
per-file [email protected]
per-file [email protected]
per-file [email protected]
per-file [email protected]
per-file [email protected]
per-file [email protected]

# COMPONENT: Blink>JavaScript>API
Loading

0 comments on commit 8dbccdc

Please sign in to comment.