Instead, cti_optimize should discover the state of its code block in a more racy way, using other available data.
This should fix crashes I'm seeing in Octane. Those crashes trip on an important RELEASE_ASSERT in the current code, and removing that assertion would not be safe. That assertion is saying that if we think that we're compiling the code then we shouldn't have an optimized replacement. Except that we might have *thought* that we were compiling code prior to a GC and then the GC synchronously completed the compilation.
That's why we need to have a way of sort of re-asking whether we ought to be:
- waiting for compilation to finish
- initiating a new compile
- OSRing into an old compile
- OSRing into a newly finished compile
Created attachment 202866 [details]
work in progress
I think I have a better way of doing this. We just need to defer GC some more.
Created attachment 202889 [details]
Comment on attachment 202889 [details]
Landed in http://trac.webkit.org/changeset/150721