I'm still working on this off-and-on. The issue is not as urgent as it sounds because in the case that a wrapper object is collected prematurely, we simply remake it as needed. Still, this could cause issues if scripts add JS properties on native objects and expect them to stay there, but the issues seems to be affecting only a handful of specific scripts on our platform and none of them happen to do that... Still, we do need to fix the issue for future scripts.
On Wed, Jan 16, 2019 at 2:23 AM Michael Lippautz <mlippa...@chromium.org> wrote: > - The ClearWeak part should work if there's a final GC pause interrupting > whatever is done with C++ stack. > Sorry, I'm a GC noob. What happens in the "final GC pause", exactly? What does it mean for it to "interrupt whatever is done with the C++ stack"? Does ClearWeak() implicitly mark the object, if tracing is already in-progress? Or is that what happens in the final GC pause? Does that object get traced? Looking at the code, it seems like ClearWeak() does not mark the object. So I guess I should probably RegisterExternalReference() after ClearWeak()? Normally a strong reference would be a root and so would be marked at the beginning of the trace cycle, but if ClearWeak() happens mid-cycle it seems like there's an issue. However, this doesn't seem to fit the pattern of the problems I'm seeing in production. > - The SetWeak after being done may or may not require a manual registering > call, depending on how EmbedderHeapTracer is implemented. > > In Blink we implemented regular traced garbage collection for the > EmbedderHeapTracer. This means that the object containing such an > interesting references may have been processed by the EmbedderHeapTracer > already. If the reference is then just marked as weak with SetWeak() the GC > misses out on it as it never sees the containing object again. Blink emits > a RegisterExternalReference() call for such objects. The general concept > for solving mutation in the graph while a garbage collector is running is > called (write barrier). > Not sure I follow. RegisterExternalReference() is only meaningful on objects that are currently white, right? But before SetWeak(), the handle was strong, making it a root. Roots should have been marked gray at the start of the tracer cycle? In my case, I think the objects are frequently newly-allocated at the time SetWeak() is called. But a newly-allocated object should be marked black at allocation, right? Thanks again for the help! Hopefully we'll be able to open source this glue library so others can reuse this work... -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.
