[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