[Webkit-unassigned] [Bug 79191] [JSC] The end atom of the marked block should be considered to decide if the cell is live

[bugzilla-daemon at webkit.org]

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





--- Comment #9 from Filip Pizlo <fpizlo at apple.com>  2012-02-28 12:51:21 PST ---
(In reply to comment #8)
> I've tried to find the steps to reproduce the same problem,
> but it's very difficult to artificially manipulate GC and memory allocation related to the system.
> 
> Concurrently I've been analyzing the crash already occurred.
> It tells me that there were many abandoned addresses in the register file.
> 
> Do you have ideas about the possibility that unnecessary addresses or values remain in the register file?

My immediate instinct is that this is totally unsurprising.  The register file can be quite sparse; for example a function may never touch its temporaries when it executes because it takes a path that doesn't need them.  So stale values can remain on the register file for quite some time.

> 
> The register file grows while processing in JIT code without shrink.
> I cannot find any shrink in JIT code as I've looked into it.

We rarely shrink the register file.  Though its growth should not be unbounded - it should reach steady state.  If you've found cases of unbounded stack growth, then that's a bug.

> If it just grows, there would be many unnecessary things after one of the callframes is done in JIT code.
> At last those would affect GC works.
> 
> Any comment, advice, and feedback welcomed.

The GC should be impervious to stale pointers in the register file.  That's why the stack scan has various checks.  I think the relevant question for this bug is: is the fact that we don't have a special check for a pointer being beyond m_endAtom lead to GC state being corrupted, or is it the case that either (a) the GC doesn't care or (b) the check would be redundant because our other checks (like in-middle-of-cell) already cover that case.

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