Re: [v8-users] Re: What is the purpose of isolated source group

[Mingwei Zhang]

Thank you. That solves my question.

On Wednesday, October 3, 2018 at 8:08:06 PM UTC-7, Jakob Kummerow wrote:
>
> The purpose of d8's --isolate flag is to make it possible to test that 
> scripts in different isolates can indeed run without interference from each 
> other. Such scripts cannot communicate with each other (as the name 
> "isolate" implies).
>
> On Wed, Oct 3, 2018 at 6:44 PM Mingwei Zhang  > wrote:
>
>> I realize that I made a mistake. So d8 API does provide support for 
>> Worker and I suspect developers could use postMessage to talk with each 
>> other?
>>
>> But still, I think my question remains. For a command like:
>>
>> ./d8 a.js --isolate b.js
>>
>>
>> How does a.js talk with b.js. In Worker example, a.js could to b.js 
>> because a.js launches b.js, but in this case, a.js does not even know b.js 
>> exists.
>>
>>
>> Thanks. 
>>
>> On Wednesday, October 3, 2018 at 11:45:30 AM UTC-7, Mingwei Zhang wrote:
>>>
>>> Hi,
>>>
>>> I am wondering what is the purpose of the options "--isolate" for the 
>>> stand-alone binary d8. It is pretty interesting that the option '--isolate' 
>>> could be used to launch multiple JavaScripts and runtime them truly in 
>>> parallel. However, since JavaScript is single-threaded by design. This 
>>> puzzles to me that one JavaScript file may not talk to the other one.
>>>
>>> So my purpose is to run two JS files, say a.js and b.js. Now I use this 
>>> command:
>>>
>>> ./d8 a.js --isolate b.js
>>>
>>>
>>> Now, my question is could I make a.js be able to talk to b.js in some 
>>> way?
>>>
>>> Thanks. 
>>>
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@googlegroups.com 
>> http://groups.google.com/group/v8-users
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to v8-users+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: What is the purpose of isolated source group

[Jakob Kummerow]

The purpose of d8's --isolate flag is to make it possible to test that
scripts in different isolates can indeed run without interference from each
other. Such scripts cannot communicate with each other (as the name
"isolate" implies).

On Wed, Oct 3, 2018 at 6:44 PM Mingwei Zhang  wrote:

> I realize that I made a mistake. So d8 API does provide support for Worker
> and I suspect developers could use postMessage to talk with each other?
>
> But still, I think my question remains. For a command like:
>
> ./d8 a.js --isolate b.js
>
>
> How does a.js talk with b.js. In Worker example, a.js could to b.js
> because a.js launches b.js, but in this case, a.js does not even know b.js
> exists.
>
>
> Thanks.
>
> On Wednesday, October 3, 2018 at 11:45:30 AM UTC-7, Mingwei Zhang wrote:
>>
>> Hi,
>>
>> I am wondering what is the purpose of the options "--isolate" for the
>> stand-alone binary d8. It is pretty interesting that the option '--isolate'
>> could be used to launch multiple JavaScripts and runtime them truly in
>> parallel. However, since JavaScript is single-threaded by design. This
>> puzzles to me that one JavaScript file may not talk to the other one.
>>
>> So my purpose is to run two JS files, say a.js and b.js. Now I use this
>> command:
>>
>> ./d8 a.js --isolate b.js
>>
>>
>> Now, my question is could I make a.js be able to talk to b.js in some way?
>>
>> Thanks.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: What is the purpose of isolated source group

[Mingwei Zhang]

I realize that I made a mistake. So d8 API does provide support for Worker 
and I suspect developers could use postMessage to talk with each other?

But still, I think my question remains. For a command like:

./d8 a.js --isolate b.js


How does a.js talk with b.js. In Worker example, a.js could to b.js because 
a.js launches b.js, but in this case, a.js does not even know b.js exists.


Thanks. 

On Wednesday, October 3, 2018 at 11:45:30 AM UTC-7, Mingwei Zhang wrote:
>
> Hi,
>
> I am wondering what is the purpose of the options "--isolate" for the 
> stand-alone binary d8. It is pretty interesting that the option '--isolate' 
> could be used to launch multiple JavaScripts and runtime them truly in 
> parallel. However, since JavaScript is single-threaded by design. This 
> puzzles to me that one JavaScript file may not talk to the other one.
>
> So my purpose is to run two JS files, say a.js and b.js. Now I use this 
> command:
>
> ./d8 a.js --isolate b.js
>
>
> Now, my question is could I make a.js be able to talk to b.js in some way?
>
> Thanks. 
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: well-formed JSON.stringify

[Sathya Gunasekaran]

LGTM2

On Wed, Oct 3, 2018 at 2:42 PM Adam Klein  wrote:

> LGTM
>
> On Wed, Oct 3, 2018 at 8:09 AM 'Mathias Bynens' via v8-users <
> v8-users@googlegroups.com> wrote:
>
>> Contact emails
>>
>> math...@chromium.org
>>
>> Spec
>>
>> https://github.com/tc39/proposal-well-formed-stringify
>>
>> Summary
>>
>> A Stage 3 proposal changes JSON.stringify to prevent it from returning
>> ill-formed Unicode strings.
>>
>> Motivation
>>
>> RFC 8259 section 8.1 
>> requires JSON text exchanged outside the scope of a closed ecosystem to be
>> encoded using UTF-8, but JSON.stringify
>>  can return strings
>> including code points that have no representation in UTF-8 (specifically,
>> surrogate code points U+D800 through U+DFFF). And contrary to the
>> description of JSON.stringify
>> , such strings are
>> not “in UTF-16” because “isolated UTF-16 code units in the range
>> D800₁₆..DFFF₁₆ are ill-formed” per The Unicode Standard, Version 10.0.0,
>> Section 3.4 
>> at definition D91 and excluded from being “in UTF-16” per definition D89.
>>
>> However, returning such invalid Unicode strings is unnecessary, because
>> JSON strings can include Unicode escape sequences.
>>
>> Interoperability and compatibility risk
>>
>> This change is backwards-compatible, under an assumption of consumer
>> compliance with the JSON specification. User-visible effects are limited to
>> the replacement of some rare single UTF-16 code units in JSON.stringify
>> output with equivalent six-character escape sequences that can be
>> represented both in UTF-16 and in UTF-8. Any consumer accepting the current
>> ill-formed output is unaffected by this change (this is true in particular
>> of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed
>> output will have a new opportunity to accept its well-formed
>> representation, although such consumers may still reject input that
>> specifies strings including Unicode code points that are not scalar values
>> (e.g. because they only accept I-JSON
>>  input), but those that accept it
>> must have mechanisms for dealing with unpaired surrogates (as mentioned in
>> the specification of JSON).
>>
>> This feature has a ready-to-land Firefox/SpiderMonkey implementation
>> . There are
>> tracking bugs for Edge/Chakra
>>  and
>> Safari/JavaScriptCore .
>>
>> Is this feature fully tested?
>>
>> Yes. In addition to V8’s own tests (
>> v8/test/mjsunit/harmony/well-formed-json-stringify*.js and
>> v8/test/cctest/test-strings*), Test262 includes tests
>> 
>> for this feature .
>>
>>
Note: Mathias rolled the latest test262 tests in to V8 (
https://chromium-review.googlesource.com/c/v8/v8/+/1259865) and V8 passes
the test262 tests for this feature.


> Tracking bug
>>
>> https://bugs.chromium.org/p/v8/issues/detail?id=7782
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/5752304045129728
>>
>> Requesting approval to ship?
>>
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no signoff from Blink API owners is required.
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: well-formed JSON.stringify

[Adam Klein]

LGTM

On Wed, Oct 3, 2018 at 8:09 AM 'Mathias Bynens' via v8-users <
v8-users@googlegroups.com> wrote:

> Contact emails
>
> math...@chromium.org
>
> Spec
>
> https://github.com/tc39/proposal-well-formed-stringify
>
> Summary
>
> A Stage 3 proposal changes JSON.stringify to prevent it from returning
> ill-formed Unicode strings.
>
> Motivation
>
> RFC 8259 section 8.1 
> requires JSON text exchanged outside the scope of a closed ecosystem to be
> encoded using UTF-8, but JSON.stringify
>  can return strings
> including code points that have no representation in UTF-8 (specifically,
> surrogate code points U+D800 through U+DFFF). And contrary to the
> description of JSON.stringify
> , such strings are
> not “in UTF-16” because “isolated UTF-16 code units in the range
> D800₁₆..DFFF₁₆ are ill-formed” per The Unicode Standard, Version 10.0.0,
> Section 3.4 
> at definition D91 and excluded from being “in UTF-16” per definition D89.
>
> However, returning such invalid Unicode strings is unnecessary, because
> JSON strings can include Unicode escape sequences.
>
> Interoperability and compatibility risk
>
> This change is backwards-compatible, under an assumption of consumer
> compliance with the JSON specification. User-visible effects are limited to
> the replacement of some rare single UTF-16 code units in JSON.stringify
> output with equivalent six-character escape sequences that can be
> represented both in UTF-16 and in UTF-8. Any consumer accepting the current
> ill-formed output is unaffected by this change (this is true in particular
> of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed
> output will have a new opportunity to accept its well-formed
> representation, although such consumers may still reject input that
> specifies strings including Unicode code points that are not scalar values
> (e.g. because they only accept I-JSON
>  input), but those that accept it
> must have mechanisms for dealing with unpaired surrogates (as mentioned in
> the specification of JSON).
>
> This feature has a ready-to-land Firefox/SpiderMonkey implementation
> . There are
> tracking bugs for Edge/Chakra
>  and
> Safari/JavaScriptCore .
>
> Is this feature fully tested?
>
> Yes. In addition to V8’s own tests (
> v8/test/mjsunit/harmony/well-formed-json-stringify*.js and
> v8/test/cctest/test-strings*), Test262 includes tests
> 
> for this feature .
>
> Tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=7782
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/5752304045129728
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] What is the purpose of isolated source group

[Mingwei Zhang]

Hi,

I am wondering what is the purpose of the options "--isolate" for the 
stand-alone binary d8. It is pretty interesting that the option '--isolate' 
could be used to launch multiple JavaScripts and runtime them truly in 
parallel. However, since JavaScript is single-threaded by design. This 
puzzles to me that one JavaScript file may not talk to the other one.

So my purpose is to run two JS files, say a.js and b.js. Now I use this 
command:

./d8 a.js --isolate b.js


Now, my question is could I make a.js be able to talk to b.js in some way?

Thanks. 

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] What are the threading considerations for EmbedderHeapTracer?

['Kenton Varda' via v8-users]

On Wed, Oct 3, 2018 at 1:49 AM Michael Lippautz 
wrote:

> It appears that it's possible that an object registered with
>> EmbedderHeapTracer::RegisterV8References() can actually be collected (i.e.
>> its weak callback is called) between then and
>> EmbedderHeapTracer::AdvanceTracing(). So, in RegisterV8References() I have
>> to make sure to put all the pointers in a map. When an object is destroyed
>> while tracing is active, I have to go remove it from the tracer's map. In
>> AdvanceTracing() I can then trace whatever is still in the map at that
>> point.
>>
>> I'm not sure what mechanism causes the object to be destroyed immediately
>> after it has been registered for tracing. But, AFAICT, the object is
>> legitimately no longer reachable -- I'm not seeing any objects being
>> destroyed that were still in-use.
>>
>
> That should not be possible when everything is properly set up. Any object
> can only go away
> - on Scavenge, which should be prohibited by marking it as active in the
> prologue callbacks
> - on Mark-Compact, which should not be possible as tracing is still in
> progress.
>

This seems to have to do with MarkIndependent().

When I create a wrapper, I create one weak handle that is held by the
wrapper itself and exists solely to detect when the wrapper should be
destroyed (via the weak callback). On this handle I call MarkIndependent().
I don't quite remember why -- I probably cargo-culted it from somewhere.

It appears that handles marked independent are not visited by
VisitWeakHandles(). Hence, the scavenge prologue callback does not mark the
handle active. If this is the only handle pointing to the object, then, it
will be scavenged. But independent handles apparently are still traced,
hence it can be passed to RegisterV8References() before it is scavenged.

I think this behavior is actually overall a good thing for me. If the only
handle left pointing at an object is this fake handle that exists only to
invoke the destructor, then that object might as well be collected
immediately. Waiting through the next full trace cycle before collecting it
is a waste.

However, I notice that MarkIndependent() is deprecated, with the message:
"Objects are always considered independent." The message suggests that
MarkIndependent() has no effect, but that seems inaccurate. Is there a
preferred alternative to get the behavior I want here?

The only thing I can think of where this could happen is when V8 calls
> AdvanceTracing where it *must* trace all objects that are cached (indicated
> by completing actions in the old version, or with infinite as timeout in
> the new version) and the embedder does not follow this policy. The
> Mark-Compact collector implements various stages of weakness processing and
> an object could be collected if AdvanceTracing(infinity) does not fully
> process all objects on the embedder side. Then the next
> AdvanceTracing(infinity) call could see dead objects.
>
> Any chance that you are not completely draining all objects when it's
> required?
>

Currently, my AdvanceTracing() callback always drains the whole queue. I
haven't tried to implement deadlines.

-Kenton

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to ship: well-formed JSON.stringify

['Mathias Bynens' via v8-users]

Contact emails

math...@chromium.org

Spec

https://github.com/tc39/proposal-well-formed-stringify

Summary

A Stage 3 proposal changes JSON.stringify to prevent it from returning
ill-formed Unicode strings.

Motivation

RFC 8259 section 8.1 
requires JSON text exchanged outside the scope of a closed ecosystem to be
encoded using UTF-8, but JSON.stringify
 can return strings
including code points that have no representation in UTF-8 (specifically,
surrogate code points U+D800 through U+DFFF). And contrary to the
description of JSON.stringify
, such strings are not
“in UTF-16” because “isolated UTF-16 code units in the range D800₁₆..DFFF₁₆
are ill-formed” per The Unicode Standard, Version 10.0.0, Section 3.4
 at definition
D91 and excluded from being “in UTF-16” per definition D89.

However, returning such invalid Unicode strings is unnecessary, because
JSON strings can include Unicode escape sequences.

Interoperability and compatibility risk

This change is backwards-compatible, under an assumption of consumer
compliance with the JSON specification. User-visible effects are limited to
the replacement of some rare single UTF-16 code units in JSON.stringify
output with equivalent six-character escape sequences that can be
represented both in UTF-16 and in UTF-8. Any consumer accepting the current
ill-formed output is unaffected by this change (this is true in particular
of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed
output will have a new opportunity to accept its well-formed
representation, although such consumers may still reject input that
specifies strings including Unicode code points that are not scalar values
(e.g. because they only accept I-JSON 
input), but those that accept it must have mechanisms for dealing with
unpaired surrogates (as mentioned in the specification of JSON).

This feature has a ready-to-land Firefox/SpiderMonkey implementation
. There are tracking
bugs for Edge/Chakra 
and Safari/JavaScriptCore .

Is this feature fully tested?

Yes. In addition to V8’s own tests (
v8/test/mjsunit/harmony/well-formed-json-stringify*.js and
v8/test/cctest/test-strings*), Test262 includes tests

for this feature .

Tracking bug

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

Link to entry on the Chrome Platform Status dashboard

https://www.chromestatus.com/feature/5752304045129728

Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] What are the threading considerations for EmbedderHeapTracer?

[Michael Lippautz]

On Tue, Oct 2, 2018 at 10:12 PM 'Kenton Varda' via v8-users <
v8-users@googlegroups.com> wrote:

> On Tue, Oct 2, 2018 at 11:10 AM Michael Lippautz 
> wrote:
>
>> Glad that your setup works for you now. Is your project open source? In
>> any case, let us know if you encounter any further issues.
>>
>
> This is all for the Cloudflare Workers runtime.
> https://developers.cloudflare.com/workers/about/
>
> At present it is not open source. But, I'd very much like to release our
> C++<->V8 glue layer at some point soon. We've used a lot of template/macro
> magic to make it pretty painless to export a C++ interface to JavaScript.
>

Cool :)


>
> * When allocating a new native object, I check if a trace pass is in
>>> progress (i.e. TracePrologue() has been called but TraceEpilogue() has
>>> not). If so, I add the object to the list of objects that needs to be
>>> traced. This handles the specific case that you mentioned, where the object
>>> is allocated already-marked, and hence won't otherwise be traced as part of
>>> the current tracing pass. It looks like I can't actually do the trace
>>> synchronously when the object is created -- V8 doesn't expect
>>> RegisterExternalReference() to be called at this time and crashes. Instead,
>>> by adding it to the list, my tracer's IsTracingDone() now returns false,
>>> which leads V8 to call AdvanceTracing() at some future point, which is
>>> where I can then trace the object.
>>>
>>
>> Delaying is usually better as depending on scheduling and idleness it has
>> the potential to run in a less-busy phase of execution. That depends on the
>> kind of platform you are running on though.
>>
>> On a first look, the synchronous call to RegisterExternalReference should
>> also work though. Any chance you can pass along what's happening via bug or
>> email?
>>
>
> If I call RegisterExternalReference() without checking if a trace is in
> progress, I pretty immediately get this unhelpful error dump:
>
> #
> # Fatal error in , line 0
> # unreachable code
> #
> #
> #
> #FailureMessage Object: 0x7f638f70b980
>
> Followed by a segfault with this stack trace:
>
> :? v8::internal::ConcurrentMarking::Run(int,
> v8::internal::ConcurrentMarking::TaskState*)
> ??:? v8::platform::WorkerThread::Run()
> platform-posix.cc:? v8::base::ThreadEntry(void*)
> glibc-2.24/nptl/pthread_create.c:333 start_thread
> glibc-2.24/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97 clone
>
> It looks like if make sure only to call it if a trace is in progress, then
> it works fine.
>

Yes, that's correct. RegisterExternalReference() requires tracing to be in
progress. However, you should be able to call it from anywhere on the main
thread, e.g., also when V8 registers a reference through
RegisterV8References
.
What I meant is that there's no need to *only* process the objects during
AdvanceTracing

.


>
> * It's possible that a newly-created object will be destroyed before
>>> tracing progresses, if all handles go out-of-scope. Hence, the object's
>>> weak callback must also check if a trace is in progress, and must then
>>> remove the object from the list of objects to be traced. Otherwise,
>>> AdvanceTracing() will end up tracing a dangling pointer.
>>>
>>
>> How can it go away? IIRC, then you set up the Scavenger correctly so that
>> it would be strong and the currently running Mark-Compact GC should not be
>> able to finish without tracing it.
>>
>
> I may have misspoke slightly here: it appears the effect I was seeing is
> *not* necessarily related to newly-created objects. Let me restate.
>
> It appears that it's possible that an object registered with
> EmbedderHeapTracer::RegisterV8References() can actually be collected (i.e.
> its weak callback is called) between then and
> EmbedderHeapTracer::AdvanceTracing(). So, in RegisterV8References() I have
> to make sure to put all the pointers in a map. When an object is destroyed
> while tracing is active, I have to go remove it from the tracer's map. In
> AdvanceTracing() I can then trace whatever is still in the map at that
> point.
>
> I'm not sure what mechanism causes the object to be destroyed immediately
> after it has been registered for tracing. But, AFAICT, the object is
> legitimately no longer reachable -- I'm not seeing any objects being
> destroyed that were still in-use.
>
>
That should not be possible when everything is properly set up. Any object
can only go away
- on Scavenge, which should be prohibited by marking it as active in the
prologue callbacks
- on Mark-Compact, which should not be possible as tracing is still in
progress.

The only thing I can think of where this could happen is when V8 calls
AdvanceTracing where it *must* trace all objects that are cached (indicated
by completing