RESOLVED INVALID 110813
[JSC] Upstream iOS Stack bound checking 
https://bugs.webkit.org/show_bug.cgi?id=110813
Summary [JSC] Upstream iOS Stack bound checking
Benjamin Poulain
Reported 2013-02-25 15:18:46 PST
[JSC] Upstream iOS Stack bound checking
Attachments
Patch (6.48 KB, patch)
2013-02-25 15:20 PST, Benjamin Poulain 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Benjamin Poulain
Comment 1 2013-02-25 15:20:57 PST
Created attachment 190137 [details] Patch
Benjamin Poulain
Comment 2 2013-02-25 20:15:15 PST
Comment on attachment 190137 [details] Patch Clearing flags on attachment: 190137 Committed r144004: <http://trac.webkit.org/changeset/144004>
Benjamin Poulain
Comment 3 2013-02-25 20:15:17 PST
All reviewed patches have been landed. Closing bug.
Oliver Hunt
Comment 4 2013-02-25 20:42:31 PST
I'm sure the stack bounds used to be thread local, i'm not sure why that can't just be the rule..
Geoffrey Garen
Comment 5 2013-02-25 20:52:50 PST
I must be missing something obvious, but I don't understand why the Parser and BytecodeGenerator can't cache the stack bounds. Those are temporary, stack-local objects. Even though WebKit in general may run on the main or web thread, we shouldn't every start parsing on one thread and then switch to another, right?
Oliver Hunt
Comment 6 2013-02-25 20:55:26 PST
(In reply to comment #5) > I must be missing something obvious, but I don't understand why the Parser and BytecodeGenerator can't cache the stack bounds. Those are temporary, stack-local objects. Even though WebKit in general may run on the main or web thread, we shouldn't every start parsing on one thread and then switch to another, right? That was my thought. Many moons ago that's essentially what they did. Then gavin refactored, then the thread local disappeared. I'm not sure why exactly.
Oliver Hunt
Comment 7 2013-02-25 20:55:54 PST
(In reply to comment #5) > I must be missing something obvious, but I don't understand why the Parser and BytecodeGenerator can't cache the stack bounds. Those are temporary, stack-local objects. Even though WebKit in general may run on the main or web thread, we shouldn't every start parsing on one thread and then switch to another, right? (Also workers _do_ only run on a single thread)
Benjamin Poulain
Comment 8 2013-02-25 23:20:18 PST
Sorry, I do not have a clue, I did not work on the original bug. I did this change to avoid an horrible workaround in StackBounds. I'll try to find the original radar tomorrow.
Benjamin Poulain
Comment 9 2013-02-26 00:02:54 PST
After looking at why that was needed in the first place, I think this is wrong. Can you guys confirm we never enter the event loop or a WebKit callback from BytecodeGenerator and Parser? If that is the case, I will remove the iOS changes on both side.
Geoffrey Garen
Comment 10 2013-02-26 00:40:51 PST
> Can you guys confirm we never enter the event loop or a WebKit callback from BytecodeGenerator and Parser? Confirmed.
Benjamin Poulain
Comment 11 2013-02-26 01:11:02 PST
And done. Thank you for double checking this.
Note You need to log in before you can comment on or make changes to this bug.