[Webkit-unassigned] [Bug 12535] Stack-optimizing compilers can trick GC into freeing in-use objects

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=12535





------- Comment #12 from ian.eng.webkit at gmail.com  2007-02-02 11:14 PDT -------
(In reply to comment #8)
> (In reply to comment #6)
> >
> > > Honoring pointers to object bodies as pointers to the objects themselves seems
> > > like it would solve the problem. I worry that it might increase marking
> > > overhead substantially because we would start honoring more 'fake' pointers.
> > 
> > I think the overhead might no much. Instead of checking 
> > if (offset % sizeof(CollectorCell) == 0)
> > It does some arithmatic calculation:
> >   x = cellStart + (offset / sizeof(CollectorCell)) * sizeof(CollectorCell);
> > 
> > We need some additional work for oversized cells. Size infomation is needed. We
> > can malloc an additional int before the requested size, and store the cell size
> > into it. This works like a Java array with length in its header. BTW, I
> > experimented this change, and it works properly.
> > 
> > Overall, these only cost a few instruction cycles when scanning root pointers.
> > I think it is not a big issue.
> 
> The problem isn't the extra instructions to do the math. It's the cost of extra
> false positives. Note that right now before scanning the blocks we check:
> 
>     if (IS_CELL_ALIGNED(x) && x) {
> 
> IS_CELL_ALIGNED checks for 8-byte alignment, which is not valid if we want to
> honor arbitrary pointers into object bodies.
> 
> If we checked every nonzero value on the stack, we would do the block loop a
> lot more, which would be a significant performance regression.
> 

Maciej, is there a performance test suite to measure how much overhead it would
be? Maybe we can think about using a interval tree instead of the block loop to
speed up the range test.

Another solution is to fix these classes returning field addresses. It may not
be hard to do, but it cannot prevent violations in the future.


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