[Webkit-unassigned] [Bug 129429] [Win32][LLINT] Crash when running JSC stress tests.

[bugzilla-daemon at webkit.org]

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





--- Comment #9 from Mark Lam <mark.lam at apple.com>  2014-02-27 10:44:24 PST ---
(From update of attachment 225383)
View in context: https://bugs.webkit.org/attachment.cgi?id=225383&action=review

>> Source/JavaScriptCore/jit/AssemblyHelpers.cpp:78
>> +#if PLATFORM(WIN)
>> +// On Windows we need to check if the stack pointer moves over the stack guard page of size 4K.
>> +// If so, we need to read or write some data on every following guard page
>> +// to make sure the system commits the previously uncommitted stack memory.
>> +// Otherwise we might crash later if we access uncommitted stack memory.
>> +// See http ://msdn.microsoft.com/en-us/library/ms686774%28VS.85%29.aspx
> 
> Remove the space after "http".
> 
> I didn't see anything on the MSDN web page that each intermediate page needs to be touched when the allocation grows by multiple pages.  Did you verify this through testing?

Like Michael, I also don’t see anything from the docs at the url you provided that says that application code needs to touch the memory first.  Also, what is the difference between touching it here in moveStackPointerAndGuardPage vs touching it later?  

The only time when I can see this making a difference is if system memory is low to begin with and you’re eagerly touching it to get the physical stack pages committed before some other consumer gets it first.  If that is the case, I’m not convinced that this is a good solution.  It would involve competing in a race condition (i.e. doesn’t guarantee that we’ll succeed in claiming those pages), and it simply shifts the problem of dealing with lack of memory to some other part of the code.

Can you please provide some details (and data to back it up) on what the actual problem is that you’re trying to solve here?  If I missed the relevant details in a previous comment, please highlight it for me.  Thanks.

> Source/JavaScriptCore/llint/LowLevelInterpreter.asm:390
> +# On Windows we need to check if the stack pointer moves over the stack guard page of size 4K.
> +# If so, we need to read or write some data on every following guard page
> +# to make sure the system commits the previously uncommitted stack memory.
> +# Otherwise we might crash later if we access uncommitted stack memory.
> +# See http://msdn.microsoft.com/en-us/library/ms686774%28VS.85%29.aspx

Perhaps I’m missing it, but I don’t see anything from the docs at the url you provided that says that application code needs to touch the memory first.  Also, what is the difference between touching it here in moveStackPointerAndGuardPage vs touching it later?  

The only time when I can see this making a difference is if system memory is low to begin with and you’re eagerly touching it to get the physical stack pages committed before some other consumer gets it first.  If that is the case, I’m not convinced that this is a good solution.  It would involve competing in a race condition (i.e. doesn’t guarantee that we’ll succeed in claiming those pages), and it simply shifts the problem of dealing with lack of memory to some other part of the code.

Can you please provide some details (and data to back it up) on what the actual problem is that you’re trying to solve here?  If I missed the relevant details in a previous comment, please highlight it for me.  Thanks.

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