On Tue, Oct 2, 2018 at 11:10 AM Michael Lippautz <mlippa...@chromium.org>
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.

* 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.

* 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.

-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.

Reply via email to