PR-URL: https://github.com/nodejs/node/pull/42657
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/40178
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/39469
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
Reland "[api] JSFunction PromiseHook for v8::Context"
This is a reland of d5457f5fb7ea05ca05a697599ffa50d35c1ae3c7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
Refs: c0fceaa066
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Original commit message:
Reland "[api] JSFunction PromiseHook for v8::Context"
This is a reland of d5457f5fb7ea05ca05a697599ffa50d35c1ae3c7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
Refs: c0fceaa066
PR-URL: https://github.com/nodejs/node/pull/36394
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
[api] Add Context::GetMicrotaskQueue method
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Refs: 4bf051d536
PR-URL: https://github.com/nodejs/node/pull/36482
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
[api] Add Context::GetMicrotaskQueue method
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Refs: 4bf051d536
PR-URL: https://github.com/nodejs/node/pull/36482
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Original commit message:
Fix alloc/dealloc size mismatch for v8::BackingStore
On newer compilers the {operator delete} with explicit {size_t}
argument would be instantiated for {v8::BackingStore} and used
in the destructor of {std::unique_ptr<v8::BackingStore>}. The {size_t}
argument is wrong though, since the pointer actually points
to a {v8::internal::BackingStore} object.
The solution is to explicitly provide a {operator delete}, preventing
an implicitly generated {size_t} operator.
Bug:v8:11081
Change-Id: Iee0aa47a67f0e41000bea628942f7e3d70198b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2506712
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70916}
PR-URL: https://github.com/nodejs/node/pull/35939
Fixes: https://github.com/nodejs/node/issues/35669
Refs: 9a49b2298f
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
Fix alloc/dealloc size mismatch for v8::BackingStore
On newer compilers the {operator delete} with explicit {size_t}
argument would be instantiated for {v8::BackingStore} and used
in the destructor of {std::unique_ptr<v8::BackingStore>}. The {size_t}
argument is wrong though, since the pointer actually points
to a {v8::internal::BackingStore} object.
The solution is to explicitly provide a {operator delete}, preventing
an implicitly generated {size_t} operator.
Bug:v8:11081
Change-Id: Iee0aa47a67f0e41000bea628942f7e3d70198b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2506712
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70916}
PR-URL: https://github.com/nodejs/node/pull/35939
Fixes: https://github.com/nodejs/node/issues/35669
Refs: 9a49b2298f
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
[turbofan] Fixes for integrating the fast C API
This commit adds a few fixes neccessary for integrating the
fast C API into Blink:
- added default constructor for CFunction
- removed a bogus template specialization allowing void* params
- extended the public Isolate class
Bug: chromium:1052746
Change-Id: I4f2ba84299920e2cc9d66ec1ed59302313db6c0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120587
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66986}
Refs: 0d6debcc5f
PR-URL: https://github.com/nodejs/node/pull/33600
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32831
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
Make SetSyntheticModuleExport throw instead of crash for nonexistent export name
Per spec, Module::SetSyntheticModuleExport should throw a ReferenceError
when called with an export name that was not supplied when constructing
that SyntheticModule. Instead, the current implementation crashes with
a failed CHECK().
Add a new Module::SyntheticModuleSetExport that throws (without an ensuing
crash) for this case, and deprecate the old
Module::SetSyntheticModuleExport.
Bug: v8:9828
Change-Id: I3b3d353064c3851882781818099bd8f6ee74c809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860996
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#64438}
Refs: 777fa98cc4
PR-URL: https://github.com/nodejs/node/pull/30020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Original commit message:
[api] Add possibility for BackingStore to keep Allocator alive
Add an `array_buffer_allocator_shared` field to the
`Isolate::CreateParams` struct that allows embedders to share
ownership of the ArrayBuffer::Allocator with V8, and which in
particular means that when this method is used that the
BackingStore deleter will not perform an use-after-free access to the
Allocator under certain circumstances.
For Background:
tl;dr: This is necessary for Node.js to perform the transition to
V8 7.9, because of the way that ArrayBuffer::Allocators and their
lifetimes currently work there.
In Node.js, each Worker thread has its own ArrayBuffer::Allocator.
Changing that would currently be impractical, as each allocator
depends on per-Isolate state. However, now that backing stores
are managed globally and keep a pointer to the original
ArrayBuffer::Allocator, this means that when transferring an
ArrayBuffer (e.g. from one Worker to another through postMessage()),
the original Allocator has to be kept alive until the ArrayBuffer
no longer exists in the receiving Isolate (or until that Isolate
is disposed). See [1] for an example Node.js test that fails with
V8 7.9.
This problem also existed for SharedArrayBuffers, where Node.js
was broken by V8 earlier for the same reasons (see [2] for the bug
report on that and [3] for the resolution in Node.js).
For SharedArrayBuffers, we already had extensive tracking logic,
so adding a shared_ptr to keep alive the ArrayBuffer::Allocator
was not a significant amount of work. However, the mechanism for
transferring non-shared ArrayBuffers is quite different, and
it seems both easier for us and better for V8 from an API standpoint
to keep the Allocator alive from where it is being referenced.
By sharing memory with the custom deleter function/data pair,
this comes at no memory overhead.
[1]: https://github.com/nodejs/node/pull/30044
[2]: https://github.com/nodejs/node-v8/issues/115
[3]: https://github.com/nodejs/node/pull/29637
Bug: v8:9380
Change-Id: Ibc2c4fb6341b53653cbd637bd8cb3d4ac43809c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874347
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64542}
Refs: 6b0a9535e6
PR-URL: https://github.com/nodejs/node/pull/30020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Original commit message:
[api] Add API functions for constructing standalone BackingStores
These are useful for the cases when an embedder works with backing
stores without creating JS ArrayBuffer objects.
Bug: v8:9380
Change-Id: I452bd911e7b20fb38568f18f9d15ea1a7ffb5a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825339
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64460}
Refs: bba5f1f43d
PR-URL: https://github.com/nodejs/node/pull/30020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/30020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
