<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 10, 2017 at 9:49 PM, <a href="mailto:tevaum@gmail.com">tevaum@gmail.com</a> <span dir="ltr"><<a href="mailto:tevaum@gmail.com" target="_blank">tevaum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr" class="gmail-m_-1034268491512638281gmail_msg">Hi. I started implementing a JavaScriptCore GObject binding in [1]. This API provides two main objects: JSCContext, representing JSGlobalContextRef, and JSCValue, representing JSValueRef. It's a first patch and does't do any memory management, because I wasn't really aware of how JSC handles JSValueRefs and stuff.<div class="gmail-m_-1034268491512638281gmail_msg"><div class="gmail-m_-1034268491512638281gmail_msg"><br class="gmail-m_-1034268491512638281gmail_msg"></div><div class="gmail-m_-1034268491512638281gmail_msg">Asking on JSC list they replied that JSValues are garbage collected and when you need to keep a reference to it in the heap you should protect them. [2]</div></div></div></div></blockquote><div><br></div><div>Yes. JSValues are GC-managed ones. So if it is on machine stack / registers, it will be marked and kept alive.</div><div>And once it becomes unreachable, GC automatically collects these values.</div><div><br></div><div>Note that JSValueRef is actually the value type rather than the pointer to something. (Internally, it something the pointer to the JSString*, JSObject*.)</div><div>It should be always copied. And it should not be allocated in heap usually.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr" class="gmail-m_-1034268491512638281gmail_msg"><div class="gmail-m_-1034268491512638281gmail_msg"><div class="gmail-m_-1034268491512638281gmail_msg">This is already done by the bindings: JSValueRefs are protected on contruction of JSCValue and unprotected on destruction, but JSCValues were implemented as initially owned and noone's keeping their reference to unref them when needed.</div></div></div></div></blockquote><div><br></div><div>I think we should not protect/unprotect in API side automatically.</div><div>And I think we should not represent JSCValue as heap allocated one.</div><div>JSCValue should be represented like gint64 (value type).</div><div><br></div><div>Or if we would like to do that, I think we should separate it from the usual JSValue class.</div><div>They are responsibility of API users.</div><div>Consider the following case,</div><div><br></div><div>std::vector<JSValueRef> vector;</div><div><br></div><div>In that case, the elements of the vector is allocated in the heap. And GC does not know about this heap area.</div><div>So GC does not mark objects in this heap area. In that case, users should protect them.</div><div>But if you use JSValueRef usually (not holding it in heap), we do not need to protect it explicitly. GC will see your stack and registers.</div><div><br></div><div>I think the above use case is relatively rare: Usually, we create the JSValue on the stack and pass it though the registers.</div><div>When we would like to store these values in the heap, we should store it in JSArray (js managed object) instead of users' vector or something.</div><div><br></div><div>Protecting and unprotecting are just adding and removing the value to the set of the GC root set.</div><div>It is not free, it adds and drops the cell to and from the hash set. This is similar to V8's Persistent<>.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr" class="gmail-m_-1034268491512638281gmail_msg"><div class="gmail-m_-1034268491512638281gmail_msg"><div class="gmail-m_-1034268491512638281gmail_msg"><br class="gmail-m_-1034268491512638281gmail_msg"></div><div class="gmail-m_-1034268491512638281gmail_msg">So in the current state, we are leaking JSCValues and, as JSCValues protect JSValueRefs, memory is never freed.</div><div class="gmail-m_-1034268491512638281gmail_msg"><br class="gmail-m_-1034268491512638281gmail_msg"></div><div class="gmail-m_-1034268491512638281gmail_msg">JavaScriptCore doesn't have any API to directly free JSValueRefs, so JSCValues needs to be destructed to unprotect JSValueRefs.</div><div class="gmail-m_-1034268491512638281gmail_msg"><br class="gmail-m_-1034268491512638281gmail_msg"></div><div class="gmail-m_-1034268491512638281gmail_msg">My thought is to Adopt JSCValues when they are created using a private API in the JSCContext (jscContextAdoptJSCValue(<wbr>JSCValue*) ?). As JSCValues have a JSCContext reference, we can call jscContextAdoptJSCValue in JSCValue's constructed callback. With this private API, JSCContext will get a JSCValue reference and add it to a HashMap that will map the JSValueRef to the JSCValue. When added to the HashMap, JSCValue will be owned by the context and will be freed when the context is unrefed.</div></div><div class="gmail-m_-1034268491512638281gmail_msg"><br class="gmail-m_-1034268491512638281gmail_msg"></div><div class="gmail-m_-1034268491512638281gmail_msg">What do you think about this idea?</div><div class="gmail-m_-1034268491512638281gmail_msg"><br></div><div class="gmail-m_-1034268491512638281gmail_msg">[1] <font color="#3367d6"><u><a href="https://bugs.webkit.org/show_bug.cgi?id=164061" target="_blank">https://bugs.webkit.org/show_<wbr>bug.cgi?id=164061</a></u></font></div><div class="gmail-m_-1034268491512638281gmail_msg">[2] <a href="https://lists.webkit.org/pipermail/jsc-dev/2016-November/000084.html" class="gmail-m_-1034268491512638281gmail_msg" target="_blank">https://lists.webkit.org/<wbr>pipermail/jsc-dev/2016-<wbr>November/000084.html</a></div></div></div>
<br>______________________________<wbr>_________________<br>
webkit-gtk mailing list<br>
<a href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a><br>
<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>
<br></blockquote></div><br></div></div>