<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thanks for clarifications!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Mar 17, 2017 at 5:52 PM, Carlos Garcia Campos <span dir="ltr">&lt;<a href="mailto:cgarcia@igalia.com" target="_blank">cgarcia@igalia.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">El mié, 15-03-2017 a las 14:54 +0900, Yusuke SUZUKI escribió:<br>
&gt; On Fri, Mar 10, 2017 at 9:49 PM, <a href="mailto:tevaum@gmail.com">tevaum@gmail.com</a> &lt;<a href="mailto:tevaum@gmail.com">tevaum@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt; &gt; Hi. I started implementing a JavaScriptCore GObject binding in [1].<br>
&gt; &gt; This API provides two main objects: JSCContext, representing<br>
&gt; &gt; JSGlobalContextRef, and JSCValue, representing JSValueRef. It&#39;s a<br>
&gt; &gt; first patch and does&#39;t do any memory management, because I wasn&#39;t<br>
&gt; &gt; really aware of how JSC handles JSValueRefs and stuff.<br>
&gt; &gt;<br>
&gt; &gt; Asking on JSC list they replied that JSValues are garbage collected<br>
&gt; &gt; and when you need to keep a reference to it in the heap you should<br>
&gt; &gt; protect them. [2]<br>
&gt; &gt;<br>
&gt;<br>
&gt; Yes. JSValues are GC-managed ones. So if it is on machine stack /<br>
&gt; registers, it will be marked and kept alive.<br>
&gt; And once it becomes unreachable, GC automatically collects these<br>
&gt; values.<br>
<br>
</span>Thanks for your help Yusuke, we really need help to understand how<br>
things work in JSC to design our API.<br>
<span class=""><br>
&gt; Note that JSValueRef is actually the value type rather than the<br>
&gt; pointer to something. (Internally, it something the pointer to the<br>
&gt; JSString*, JSObject*.)<br>
&gt; It should be always copied. And it should not be allocated in heap<br>
&gt; usually.<br>
&gt;  <br>
&gt; &gt; This is already done by the bindings: JSValueRefs are protected on<br>
&gt; &gt; contruction of JSCValue and unprotected on destruction, but<br>
&gt; &gt; JSCValues were implemented as initially owned and noone&#39;s keeping<br>
&gt; &gt; their reference to unref them when needed.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I think we should not protect/unprotect in API side automatically.<br>
&gt; And I think we should not represent JSCValue as heap allocated one.<br>
&gt; JSCValue should be represented like gint64 (value type).<br>
<br>
</span>What we really have is not a heap allocated JSValueRef, but a heap<br>
allocated GObject wrapper for a JSValueRef. Similar to what JSValue is<br>
in the Objc API, a NSObject wrapping a JSValueRef. So, for example:<br>
<br>
JSCValue *jsc_boolean_new (JSCContext *, gboolean);<br>
<br>
JSCValue is the wrapper, and this simply calls JSValueMakeBoolean to<br>
create the JSVAlueRef wrapped by this GObject.<br></blockquote><div><br></div><div>OK, so, in that case, JSCValueRef is stored in JSCValue. And JSCValue is allocated in the heap.</div><div>Yeah, right. In that case, we should protect that value.</div><div>I&#39;ve just looked JSValue.mm &amp; JSValue.h. Yup, they use protect/unprotect to offer such JSValue thing :) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the Objc API values are always protected on construction and<br>
unprotected on destruction. However, it also has API to create managed<br>
values, that I think they are like a weak ref.<br></blockquote><div><br></div><div> [JSValue valueWithJSValueRef:inContext:]?</div><div>It seems that resulted JSValue is autorelease-ed. And they are held in weak map, thus we can internalize JSValues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt; Or if we would like to do that, I think we should separate it from<br>
&gt; the usual JSValue class.<br>
&gt; They are responsibility of API users.<br>
&gt; Consider the following case,<br>
&gt;<br>
&gt; std::vector&lt;JSValueRef&gt; vector;<br>
&gt;<br>
&gt; In that case, the elements of the vector is allocated in the heap.<br>
&gt; And GC does not know about this heap area.<br>
&gt; So GC does not mark objects in this heap area. In that case, users<br>
&gt; should protect them.<br>
<br>
</span>What we have is something like this:<br>
<br>
typedef struct _JSCValuePrivate {<br>
    JSCContext* context;<br>
    JSValueRef value;<br>
} JSCValuePrivate;<br>
<br>
And yes, that struct is always heap allocated.<br></blockquote><div><br></div><div>OK, in that case, we should protect/unprotect it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt; But if you use JSValueRef usually (not holding it in heap), we do not<br>
&gt; need to protect it explicitly. GC will see your stack and registers.<br>
&gt;<br>
&gt; I think the above use case is relatively rare: Usually, we create the<br>
&gt; JSValue on the stack and pass it though the registers.<br>
&gt; When we would like to store these values in the heap, we should store<br>
&gt; it in JSArray (js managed object) instead of users&#39; vector or<br>
&gt; something.<br>
&gt;<br>
&gt; Protecting and unprotecting are just adding and removing the value to<br>
&gt; the set of the GC root set.<br>
<br>
</span>So, I guess that if I create a JSValue that is heap allocated on a<br>
context, and then I unprotect it, forcing a full GC would delete the<br>
JSValue immediately, right?</blockquote><div><br></div><div>Is there any reference to the managed value in registers / stack(it includes x64 red zone)? (even such registers are not used)</div><div>I guess GC marks it alive because of this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think I tried this for testing when we<br>
started to work on this API and didn&#39;t work for me, that&#39;s why I&#39;m<br>
asking.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; It is not free, it adds and drops the cell to and from the hash set.<br>
&gt; This is similar to V8&#39;s Persistent&lt;&gt;.<br>
&gt;  <br>
&gt; &gt; So in the current state, we are leaking JSCValues and, as JSCValues<br>
&gt; &gt; protect JSValueRefs, memory is never freed.<br>
&gt; &gt;<br>
&gt; &gt; JavaScriptCore doesn&#39;t have any API to directly free JSValueRefs,<br>
&gt; &gt; so JSCValues needs to be destructed to unprotect JSValueRefs.<br>
&gt; &gt;<br>
&gt; &gt; My thought is to Adopt JSCValues when they are created using a<br>
&gt; &gt; private API in the JSCContext (jscContextAdoptJSCValue(<wbr>JSCValue*)<br>
&gt; &gt; ?). As JSCValues have a JSCContext reference, we can call<br>
&gt; &gt; jscContextAdoptJSCValue in JSCValue&#39;s constructed callback. With<br>
&gt; &gt; this private API, JSCContext will get a JSCValue reference and add<br>
&gt; &gt; it to a HashMap that will map the JSValueRef to the JSCValue. When<br>
&gt; &gt; added to the HashMap, JSCValue will be owned by the context and<br>
&gt; &gt; will be freed when the context is unrefed.<br>
&gt; &gt;<br>
&gt; &gt; What do you think about this idea?<br>
&gt; &gt;<br>
&gt; &gt; [1] <a href="https://bugs.webkit.org/show_bug.cgi?id=164061" rel="noreferrer" target="_blank">https://bugs.webkit.org/show_<wbr>bug.cgi?id=164061</a><br>
&gt; &gt; [2] <a href="https://lists.webkit.org/pipermail/jsc-dev/2016-November/000084" rel="noreferrer" target="_blank">https://lists.webkit.org/<wbr>pipermail/jsc-dev/2016-<wbr>November/000084</a><br>
&gt; &gt; .html<br>
&gt; &gt;<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; webkit-gtk mailing list<br>
&gt; &gt; <a href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a><br>
&gt; &gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-gtk" rel="noreferrer" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-gtk</a><br>
&gt; &gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; webkit-gtk mailing list<br>
&gt; <a href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a><br>
&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-gtk" rel="noreferrer" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-gtk</a><br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Carlos Garcia Campos<br>
<a href="http://pgp.rediris.es:11371/pks/lookup?op=get&amp;search=0xF3D322D0EC4582C3" rel="noreferrer" target="_blank">http://pgp.rediris.es:11371/<wbr>pks/lookup?op=get&amp;search=<wbr>0xF3D322D0EC4582C3</a></font></span></blockquote></div><br></div></div>