Bug 116748

Summary: fourthTier: cti_optimize shouldn't allow GCs to get in the way of it seeing the state of its CodeBlock
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: JavaScriptCoreAssignee: Filip Pizlo <fpizlo>
Status: RESOLVED FIXED    
Severity: Normal CC: barraclough, ggaren, mark.lam, mhahnenberg, msaboff, oliver, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 112836    
Attachments:
Description Flags
work in progress
none
the patch ggaren: review+

Filip Pizlo
Reported 2013-05-24 16:49:51 PDT
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 - etc.
Attachments
work in progress (14.38 KB, patch)
2013-05-24 16:50 PDT, Filip Pizlo
no flags
the patch (4.62 KB, patch)
2013-05-25 09:28 PDT, Filip Pizlo
ggaren: review+
Filip Pizlo
Comment 1 2013-05-24 16:50:44 PDT
Created attachment 202866 [details] work in progress
Filip Pizlo
Comment 2 2013-05-24 19:39:00 PDT
I think I have a better way of doing this. We just need to defer GC some more.
Filip Pizlo
Comment 3 2013-05-25 09:28:17 PDT
Created attachment 202889 [details] the patch
Geoffrey Garen
Comment 4 2013-05-26 11:42:13 PDT
Comment on attachment 202889 [details] the patch r=me
Filip Pizlo
Comment 5 2013-05-26 11:44:42 PDT
Note You need to log in before you can comment on or make changes to this bug.