[Webkit-unassigned] [Bug 27077] Workers + garbage collector: weird crashes

[bugzilla-daemon at webkit.org]

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


Gavin Barraclough <barraclough at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |zherczeg at inf.u-szeged.hu
         Resolution|FIXED                       |




--- Comment #15 from Gavin Barraclough <barraclough at apple.com>  2009-07-16 21:00:16 PDT ---
Sorry, but reverted in r46004, unfortunately this does not appear to be a valid
fix.

This change will cause the method check optimization to be invalidated upon the
first JSFunction referencing a codeblock being GC'ed.  This is unnecessarily
conservative, and does not appear to be addressing the real cause of the bug. 
(This patch may well just be masking the issue by changing when GC occurs.)

Consider the following code fragment:

a = { b:(function() {}) };
function c() { return (function(d) { d.b(); }); }
e = c();
for (i=0; i<5; ++i) e(a);
f = c();
f = null;
gc();
e(a);

'a' is an object with a method 'b'.
'c' is a function that produces a closure, that will make a method call to 'b'
its argument.
'e' is a function created by 'c';
'e' is called repeatedly, which makes a method call to 'b' on its argument,
which is 'a'.  This will cause the call in the closure to be optimized to call
the function that is the property 'a.b'.
A new JSFunction referencing the same closure is created and assigned to 'f',
then overwritten.
The gc runs, which will reap the initial value of 'f', and when the
JSFunction's destructor is run unlinkCallers will be called on the closure's
CodeBlock.
With the (now reverted) patch, this will de-optimize the method call so that it
no longer is optimized to call 'a.b'.
The final call 'e(a)'; will again call the method 'a.b()' (via the closure),
however this time the method call will not be optimized.

The de-optimization described above is unnecessary and undesired.  The
optimized method check within the closure is still perfectly valid.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.