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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=154808

--- Comment #10 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #9)
> (In reply to comment #8)
> > Comment on attachment 286601 [details]
> > Patch
> > 
> > You shouldn't be adding any new fields to CodeBlock. 
> > 
> > The DFG already has a mechanism for strongly marking objects known to the
> > compiler such as the RegExps. It's called freezing: just do
> > m_graph.freezeStrongly(...). 
> > 
> > You don't need to record the RegExp object anywhere other than the NewRegExp
> > node. That node should not have an index into any vectors. It should just
> > hold a pointer to RegExp. We already do this for other node types. See for
> > example Node::cellOperand(). Notice that its already compatible with
> > freezing.
> 
> Thank you for this info. I really didn't know about that. I took a look in
> code using the freezing and it looks simpler and more correct than my
> current patch. Just for curiosity, as I understood, this Freeze mechanism
> interact with the GC, right? If yes, How does it happen?

There's a lot of logic there:

- Freezing causes the resulting CodeBlock to have either a strong or weak reference to the frozen object, depending on whether you froze it strongly or weakly.

- Freezing immediately causes the ongoing DFG compilation plan to track the reference if a GC happens while the compiler is running.  The GC knows how to safepoint the compiler.  This means that from the compiler's standpoint, GCs can only happen at well-defined points: either before the compiler started, during B3 compilation, or after the compiler finished.

There are a lot of other details; I can't remember all of them off the top of my head.  The short version is just: we already use freezing a lot, and it's designed exactly for what you want: you have some object that the generated code will refer to and you want to make sure that this object gets marked.

-- 
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/0b45643b/attachment.html>