Bug 102854 – [V8] Unify the Node and non-Node code paths for getting JavaScript wrappers

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Adam Barth]

[V8] Unify the Node and non-Node code paths for getting JavaScript wrappers

[Adam Barth]

Created attachment 175319 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 175319 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=175319&action=review

> Source/WebCore/ChangeLog:10
> +        should not be as fast to access as Nodes were previously.

should now?

> Source/WebCore/ChangeLog:26
> +              DOM object has a wrapper both on the main thread and on a worker
> +              thread, we'll have a write conflict as both threads will want to
> +              store the wrapper inline in the object.

We have an ASSERT to catch that, no?

[WebKit Review Bot]

Comment on attachment 175319 [details]
Patch

Attachment 175319 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14913826

New failing tests:
fast/workers/worker-close-more.html
fast/workers/dedicated-worker-lifecycle.html
fast/workers/worker-lifecycle.html

[Adam Barth]

Created attachment 175543 [details]
Leaks objects in workers

[Adam Barth]

The part I got hung up on here was trying to make ScriptWrappable work in workers.  On worker shutdown, we need to clear out the JavaScript wrappers and deref the underlying objects.  If we use ScriptWrappable, we no longer have the hashmap to enumerate.  I tried enumerating the handles from the V8 global handle table, but that fails if the worker is terminated via terminate() because the handle table is already destroyed by the time we get around to clearing out the wrappers.

[Anders Carlsson]

V8 is gone.