* The `Default` trait did not actually get derived for `SharedPtr<T>`.
This is solved by implementing `Default` manually.
* Trait function `Shared::get()` used to return a mutable raw pointer
(`*mut Self`), but it would be inconceivable to ever mutate the
referenced value. It was changed to return a const pointer instead.
* Added some basic unit tests for types `SharedPtr` and `SharedRef`.
After the upgrade some Deno tests started crashing somewhere deep inside
V8, and the cause of these crashes is unclear.
This reverts the following commits:
* 12334ffe Upgrade gn to 6f13aaac; make BUILD.gn compatible with it (#443)
* f53f10d4 Upgrade V8 to 8.7.25 (#443)
There currently is a problem related to Github Actions in general or the
'actions-rs/cargo' action in particular, which causes cargo to be unable
to find the 'serde_derive' crate when the cargo home dir has been
restored from cache.
This issue is also being reported by others, e.g. at
https://github.com/actions-rs/cargo/issues/111.
Isolate::run_microtasks() already exists but the microtasks queue
is also flushed on script entry and exit. Some embedders want strict
control over when microtasks run, which is set by the policy.
And deprecate Isolate::run_microtasks(). The corresponding V8 API is
tagged with V8_DEPRECATE_SOON.
After upgrading to V8 8.6.337, with a 20 MB heap limit, the
near-heap-limit callback never gets called before V8 runs out of memory.
It turns out that this test exhibits memory allocation behavior which
produces so little actual garbage that 'scavenge' type garbage
collections make memory usage go up rather than down. Because of this,
V8 runs out of memory in the middle of a garbage collection cycle, after
it has already decided that there's no need to run the near-heap-limit
callback.
The issue is fixed by making sure that some actual garbage is produced
alongside with the retained objects that will eventually fill up the
heap.
Certain callbacks (e.g. `WasmLoadSourceMapCallback`) expect the
embedder to return a local handle (a `Local<String>` in this case), but
do not provide a `Local<Context>` as an argument, nor does it provide
any other argument that we might obtain a context from. This is not
unexpected - WASM execution as such is not tied to a context, and a
`Local<String>` can be created without a context too because it's a
primitive value that has no JavaScript prototype.