Bug 29077 - [v8] Share persistent context handles between events
Summary: [v8] Share persistent context handles between events
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 30648
  Show dependency treegraph
 
Reported: 2009-09-09 01:13 PDT by Christian Plesner Hansen
Modified: 2009-10-21 20:46 PDT (History)
5 users (show)

See Also:


Attachments
initial (18.53 KB, patch)
2009-09-09 01:15 PDT, Christian Plesner Hansen
no flags Details | Formatted Diff | Diff
updated (21.37 KB, patch)
2009-09-10 04:32 PDT, Christian Plesner Hansen
abarth: commit-queue-
Details | Formatted Diff | Diff
tweaks (21.30 KB, patch)
2009-09-11 00:52 PDT, Christian Plesner Hansen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Plesner Hansen 2009-09-09 01:13:00 PDT
Change events to use a single ref-counted shared persistent handle to the context in which to run, rather than create a new persistent handle for each new event which puts pressure on the gc.
Comment 1 Christian Plesner Hansen 2009-09-09 01:15:24 PDT
Created attachment 39253 [details]
initial
Comment 2 Adam Barth 2009-09-09 08:33:50 PDT
Comment on attachment 39253 [details]
initial

SharedV8Context doesn't really have anything to do with contexts.  We should make it more general (templated?) and put it in its own header, like OwnHandle.  You might want to call it something like RefCountedHandle or something.

Aside from that, this patch looks good.
Comment 3 Adam Barth 2009-09-09 08:34:31 PDT
Also, why not make the destructor Dispose and Clear the handle if that hasn't happened already?
Comment 4 Adam Barth 2009-09-09 08:43:30 PDT
Actually, SharedHandle is a good name.  You should also considering defining a typedef that defines RefHandle<T> as RefPtr<SharedHandle<T> >.
Comment 5 Christian Plesner Hansen 2009-09-10 04:32:49 PDT
Created attachment 39340 [details]
updated
Comment 6 Adam Barth 2009-09-10 09:28:54 PDT
Comment on attachment 39340 [details]
updated

+ PassRefPtr<SharedPersistent<v8::Context> > context = proxy->shared_context();

We don't usually hold PassRefPtrs as local variables.  They're a bit tricky to use like this b/c they like to null themselves out.  In this case, we're fine, but I wanted to make sure you're realized what you were doing was somewhat subtle.

+        No new tests. (OOPS!)

This line will be rejected by the pre-submit checks.  We can either land this manually, or we can land it automatically if you upload a new patch without this line.
Comment 7 Christian Plesner Hansen 2009-09-10 09:43:30 PDT
(In reply to comment #6)
> (From update of attachment 39340 [details])
> + PassRefPtr<SharedPersistent<v8::Context> > context = proxy->shared_context();
> 
> We don't usually hold PassRefPtrs as local variables.  They're a bit tricky to
> use like this b/c they like to null themselves out.  In this case, we're fine,
> but I wanted to make sure you're realized what you were doing was somewhat
> subtle.

No, it should have been a RefPtr.  I'd prefer to fix it even though it happens to work here.

> +        No new tests. (OOPS!)
> 
> This line will be rejected by the pre-submit checks.  We can either land this
> manually, or we can land it automatically if you upload a new patch without
> this line.

I'll upload a new patch with the above change and this line removed.
Comment 8 Christian Plesner Hansen 2009-09-11 00:52:12 PDT
Created attachment 39413 [details]
tweaks
Comment 9 Adam Barth 2009-09-11 01:02:06 PDT
Comment on attachment 39413 [details]
tweaks

I'm worried about how this interacts with weak handles.  For example, we lose

- m_context.makeWeak();

in V8AbstractEventListener.cpp.  That seems like it might cause problems...

Also,

-    m_context.MakeWeak(this, &contextWeakReferenceCallback);
+    m_context->get().MakeWeak(this, &contextWeakReferenceCallback);

in V8IsolatedWorld.cpp.  Won't that make the shared handle weak?  Doesn't V8Proxy need to hold a strong reference to the context?
Comment 10 Christian Plesner Hansen 2009-09-11 01:31:37 PDT
> I'm worried about how this interacts with weak handles.  For example, we lose
> 
> - m_context.makeWeak();
> 
> in V8AbstractEventListener.cpp.  That seems like it might cause problems...

Before, each OwnHandle had its own persistent handle it needed to manager.  Now the event is sharing the handle of the frame or isolated world to which it belongs the owner takes care of that.

> Also,
> 
> -    m_context.MakeWeak(this, &contextWeakReferenceCallback);
> +    m_context->get().MakeWeak(this, &contextWeakReferenceCallback);
> 
> in V8IsolatedWorld.cpp.  Won't that make the shared handle weak?  Doesn't
> V8Proxy need to hold a strong reference to the context?

Yes, it will make the shared handle weak.  But that's no different from how it was before really except that before there was as many handles as there were event listeners, all of them weak, whereas now there is just one.
Comment 11 Adam Barth 2009-09-11 02:16:00 PDT
> Before, each OwnHandle had its own persistent handle it needed to manager.  Now
> the event is sharing the handle of the frame or isolated world to which it
> belongs the owner takes care of that.

But you see that the lifetime of the handle has changed right?  We need to think carefully and make sure that the new lifetime is ok for the event listeners.  The key point is that the event listeners won't fire when they ought not to fire.  We have some amount of test coverage for this, but it's not complete.

Maybe we're ok because V8Proxy explicitly Disposes / Clears the shared context when it would have dropped its strong handle before?

> > Also,
> > 
> > -    m_context.MakeWeak(this, &contextWeakReferenceCallback);
> > +    m_context->get().MakeWeak(this, &contextWeakReferenceCallback);
> > 
> > in V8IsolatedWorld.cpp.  Won't that make the shared handle weak?  Doesn't
> > V8Proxy need to hold a strong reference to the context?
> 
> Yes, it will make the shared handle weak.  But that's no different from how it
> was before really except that before there was as many handles as there were
> event listeners, all of them weak, whereas now there is just one.

The whole thing is super confusing though.  If you're in the main world, it just so happens that the shared context is a strong reference to the context, but when you're in an isolated world, the shared handle is weak.  All the clients of V8Proxy::context(Frame*) now have to be prepared to deal with either case.

Maybe we're ok because these clients already have to worry about this issue?

Anyway, it's after 2 a.m. here.  I'll take a look at it again tomorrow when I'm more awake.

Ager, any insight that you have would be appreciated.
Comment 12 Christian Plesner Hansen 2009-09-11 02:28:04 PDT
> But you see that the lifetime of the handle has changed right?  We need to
> think carefully and make sure that the new lifetime is ok for the event
> listeners.  The key point is that the event listeners won't fire when they
> ought not to fire.  We have some amount of test coverage for this, but it's not
> complete.
> 
> Maybe we're ok because V8Proxy explicitly Disposes / Clears the shared context
> when it would have dropped its strong handle before?

The handle is disposed by the proxy at the same time now as before.  What is different is that before event would hang on to the context from the V8Proxy had disposed its handle and until the next gc (which, incidentally, made event behavior non-deterministic) whereas now events lose access to the context immediately.  I would expect that to be 

> The whole thing is super confusing though.  If you're in the main world, it
> just so happens that the shared context is a strong reference to the context,
> but when you're in an isolated world, the shared handle is weak.  All the
> clients of V8Proxy::context(Frame*) now have to be prepared to deal with either
> case.
> 
> Maybe we're ok because these clients already have to worry about this issue?

The handle returned here will behave exactly the same as before since it's returned directly from the owner who has the same behavior as before.
Comment 13 Adam Barth 2009-09-11 10:48:16 PDT
Comment on attachment 39413 [details]
tweaks

Ok.  I'm sold.  Thanks for explaining this to me.
Comment 14 WebKit Commit Bot 2009-09-11 10:59:22 PDT
Comment on attachment 39413 [details]
tweaks

Clearing flags on attachment: 39413

Committed r48306: <http://trac.webkit.org/changeset/48306>
Comment 15 WebKit Commit Bot 2009-09-11 10:59:28 PDT
All reviewed patches have been landed.  Closing bug.
Comment 16 Dimitri Glazkov (Google) 2009-10-21 20:46:32 PDT
Christian, I am undoing most of this work in bug 30648, but not because your code was wrong -- we no longer have to hold on to the context in an event listener. Can you take a look/see?