[Webkit-unassigned] [Bug 154808] NewRegexp should not prevent inlining

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 22 22:45:41 PDT 2016


--- Comment #7 from Caio Lima <ticaiolima at gmail.com> ---
Comment on attachment 286601
  --> https://bugs.webkit.org/attachment.cgi?id=286601

View in context: https://bugs.webkit.org/attachment.cgi?id=286601&action=review

>> 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.

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] - https://github.com/WebKit/webkit/blob/e9acddff34511e7f3e184b6e6f34897027e8b61e/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h#L452

>> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:5428
>> +    // nodes.
> I don't fully understand this comment.

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.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160823/d61f71ec/attachment.html>

More information about the webkit-unassigned mailing list