<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - NewRegexp should not prevent inlining"
href="https://bugs.webkit.org/show_bug.cgi?id=154808#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - NewRegexp should not prevent inlining"
href="https://bugs.webkit.org/show_bug.cgi?id=154808">bug 154808</a>
from <span class="vcard"><a class="email" href="mailto:ticaiolima@gmail.com" title="Caio Lima <ticaiolima@gmail.com>"> <span class="fn">Caio Lima</span></a>
</span></b>
<pre>Comment on <span class=""><a href="attachment.cgi?id=286601&action=diff" name="attach_286601" title="Patch">attachment 286601</a> <a href="attachment.cgi?id=286601&action=edit" title="Patch">[details]</a></span>
Patch
View in context: <a href="https://bugs.webkit.org/attachment.cgi?id=286601&action=review">https://bugs.webkit.org/attachment.cgi?id=286601&action=review</a>
<span class="quote">>> Source/JavaScriptCore/bytecode/CodeBlock.h:900
>> + Vector<RegExp*> m_regExps;
>
> Why is it OK to store raw pointers to RegExp without a write barrier operation? You've explained why we can't do write barrier operations on the compilation thread, but I don't think you've explained why it's OK just to skip them -- and I don't think it is OK.</span >
I am using this Vector to store the RegExp from inlined functions and also store the RegExp from its own m_unlikedCode. In my current investigation and I tried to replicate it in JSTests/stress/new-regex-inline.js, and the RegExp pointer is valid while its UnlikedCode is not collected by GC. The WriteBarrie is strictly necessary in this case, otherwise it is not safe manipulate RegExp objects. So, In my understand, we need to keep unlinkedCodeBlock->m_regexps [1], because it is the reason that RegExp* aren't collected by GC and remain valid in execution context.
However, I agree with you that we can improve this implementation. I have the following changes in my mind:
1. remove all regExpList* methods I created;
2. Store RegEx from inlined functions in CodeBlock->m_rareData->m_inlinedRegexps as Vector<RegExp*> (consider it as a Weak pointer for "GC eyes");
3. In regex() check if "index < m_unlinkedCode->numberOfRegExps()" and if it is false, get the element in CodeBlock->m_rareData->m_inlinedRegexps (we avoid waste space);
To 2. be valid, what I need to be sure is if (Inlined Function CodeBlock)->m_unlikedCode->regexps [1] is not collected in GC phase. I accept help here to be 100% sure that it is a valid implementation. I am trying to debug GC with JSTests/stress/new-regex-inline.js and also --logGC=2.
It is extremely helpful if you know a way to check if (Inlined Function CodeBlock)->m_unlikedCode is collected in "gc()" and I would be happy learning it. My Assumption is that if UnlinkedCode is not collected, m_regexps are pointed to them and won't be collected too. Does it make sense to you?
[1] - <a href="https://github.com/WebKit/webkit/blob/e9acddff34511e7f3e184b6e6f34897027e8b61e/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h#L452">https://github.com/WebKit/webkit/blob/e9acddff34511e7f3e184b6e6f34897027e8b61e/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h#L452</a>
<span class="quote">>> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:5428
>> + // nodes.
>
> I don't fully understand this comment.</span >
I think it is confusing. What I am trying to say here is that we are mapping regExps from callee into machine code block to enable inlining, and we are also "mapping" machine code block's own RegExps into m_regexpRemap (but it is an identity mapping m_regexpRemap[i] == byteCodeParser->m_codeBlock->m_unlinkedCodeBlock->m_regexps[i]).
Since we are planing change this implementation, it is going to be Out of Date.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>