[webkit-gtk] Memory management for JavaScriptCore objects
Michael Gratton
mike at vee.net
Thu Jan 5 23:02:06 PST 2017
On Mon, Jan 2, 2017 at 8:13 PM, Carlos Garcia Campos
<cgarcia at igalia.com> wrote:
> El lun, 02-01-2017 a las 11:47 +1100, Michael Gratton escribió:
>>
> Yes, we plan to have GObject bindings of JSC that would make your life
> easier. There's a wip patch in [1] that is waiting review (I've been
> quite busy, but it's still in my TODO). Memory management is indeed
> the
> main challenge, because it requires to have a good knowledge of JSC
> internals and how the garbage collector works. It's also important to
> understand how apps will use the API to try to make the lib as
> convenient as possible, so your feedback would be really useful.
Thanks for pointing that bug out, I just added some comments to it
then, but in short it's about 95% there to covering Geary's current use
cases.
>> I've been trying to work out when to use functions like
>> JSGlobalContextRelease, JSStringRelease, and JSValueUnprotect, but
>> haven't been able to find any useful documentation about it. Also,
>> examples on the web seem to conflict: E.g. The WebKitGTK docs and
>> Cookbook[1] uses JSStringRelease on a string copied from a
>> JSValueRef,
>> whereas others (e.g. [2]) suggest that JSStringRelease only needs to
>> be
>> used in certain instances, or that it needs to be used all the time.
>> Any pointers to canonical docs and examples would be appreciated.
>
> JavaScript objects are garbage collected, that affects JSValueRef,
> JSObjectRef, but not JSGlobalContext or JSString. You should always
> release those. JSValueUnprotectc is not comparable with
> JSGlobalContextRelease or JSStringRelease, Release methods do actually
> release/free/unrefs the objects, but Unprotect tells the garbage
> collector that it's ok to release that object. It only makes sense if
> the value has been protected before, note that values are not
> protected
> by default.
That makes sense.
>> I assume I never need to release a JSGlobalContextRef obtained from
>> JavascriptResult or Frame, since the web process will effectively
>> retain it, but what about the others? Would it hurt to call
>> JSGlobalContextRelease and JSStringRelease even if not needed? What
>> about JSValueRefs?
>
> Yes, the global context returned by
> webkit_frame_get_javascript_global_context() is owned by WebKit, it's
> transfer-none. You shouldn't Unprotect values returned by
> WebKitJavaScriptResult either, unless you explicitly protect them, of
> course. But you should release strings returned by JSValueRef.
Diito, however WebKitJavaScriptResult presumably needs to be un-refed
via webkit_javascript_result_unref() after it has been obtained from a
WebView/UserContentManager?
>> Also, my assumption that JSC objects should be treated as Vala
>> simple
>> types, i.e. they should be passed as copies (not by reference),
>> that's
>> correct isn't it?
>
> I'm not sure, because I don't know anything about vala, but JSValueRef
> is a pointer.
>
> Most of the questions are not specific to WebKitGTK+, but to
> JavaScriptCore C API which is cross-platform, so I would ask in
> webkit-
> dev mailing list, since JSC developers can answer the questions much
> better than me :-)
Fair enough. This approach seems to be working reasonably well for now,
but I'll ping webkit-
dev if I have any more in-depth queries about JSC.
Thanks for the assistance!
//Mike
PS: I was wondering if the WebKitGTK+ team is aware of Bug 88595[0] -
basically a request for exposing the UndoManager, which would be very
useful to be able to query the state of the stack and add custom
transactions to it. I ask since the bug doesn't seem to reference GTK
except in the summary, or CC any GTK people.
[0] - <https://bugs.webkit.org/show_bug.cgi?id=88595>
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
More information about the webkit-gtk
mailing list