[Webkit-unassigned] [Bug 91354] Machine stack marker should not gather values already piled up on the stack before JSC working

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Hojong Han <hojong.han at samsung.com>  2012-11-28 04:09:37 PST ---
(In reply to comment #6)
It's been a long time since relevant comments were updated but I still want to figure it out and fix this correctly.
There are many environment variables from the top of the stack. These are sequential characters and considered as pointers during GC. For example, 0x726F6F74 means ascii "root". If it were just considered as address, It would cause a copied block made later to be pinned. This is all about what happens here.
> 
> If a particular range of stack reproducibly produces increasing numbers of pointers into the copied space, then it's highly unlikely that this is due to coincidental pointers.  I think you should figure out exactly why that region of stack tends to point into the heap.
> 
> But more importantly, I don't believe that your change is sound.  You haven't proved that a pointer can't legitimately escape into the range of stack you're talking about.  If a pointer does legitimately escape and you don't pin the relevant blocks, then bad things will happen.
> 
> You can of course do a number of other things, other than your current patch, that could overcome this problem.  Two classical approaches exist:
> 
> 1) Blacklisting.  Whenever you see a value that points to a region of virtual memory in which you have not yet allocated blocks but in which you may allocate blocks in the future, then mark that block as unusable due to the risk of false-positives.  See http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html and http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi93.ps.Z
> 
> 2) Conditional pinning for the C stack.  A pointer directly into the copied space may only exist on the C stack if there is, at time of GC, already a GC object in marked space that also points to the same copied space block.  This is not true of the JS stack, so this will only work for the C stack.  Hence, if a copied block is pinned from the C stack, you can recycle it at end of GC if no object in marked space pointed to the same copied space chunk that the C stack pointer pointed to.
> 
Do you think that your second idea is still good for this?
What about setting another origin just for machine stack marker right after WebProcess main runs?
> Please either clarify exactly why the C stack range you are worried about has increasing numbers of pointers into the copied space, or implement one of the two other approaches.

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