Request for approval: 6929067: Stack guard pages should be removed when thread is detached

[David Holmes]

David Holmes said the following on 08/19/10 09:26:
> Coleen Phillimore said the following on 08/19/10 05:01:
> 
>> I don't know that much about this, but can you have the growable 
>> mapping check we have for the primordial thread only and an assert for 
>> the other threads, in case they get this growable mapping someday?
> 
> Sure.

Ooops! No. We're going to execute this logic only if in the initial 
thread, but it's still on the path for all threads. Do be able to assert 
we would need to be able to detect that the thread is using a growable 
stack but is not the main thread. If we had such a check then we would 
use it directly rather than querying if it is the initial thread.

Hope that makes sense.

David

> 
>> David, are you going to make these changes?
> 
> Once we've validated the fix I'll see about getting it into OpenJDK
> 
> David
> 
>> Thanks,
>> Coleen
>>
>> On 08/17/10 04:14, Andrew Haley wrote:
>>> On 08/16/2010 11:57 PM, David Holmes wrote:
>>>  
>>>> Andrew Haley said the following on 08/16/10 18:42:
>>>>    
>>>>> On 08/16/2010 03:46 AM, David Holmes wrote:
>>>>>      
>>>>>> Looking further into this, isn't the only thread that can be 
>>>>>> affected by
>>>>>> this the main thread? So we could perform this only if
>>>>>> os::is_initial_thread() returns true?
>>>>>>         
>>>>> I suppose we could, yes.  I wonder if it'd be a latent bug to assume
>>>>> that Java threads could never use growable mappings, though.  Doing
>>>>> this makes the system a bit less robust.
>>>>>       
>>>> As I understand it neither LinuxThreads nor NPTL have used growable
>>>> mappings for a very long time. Even if there were a reason to go 
>>>> back to
>>>> this it would have to be done in a compatible way and so there would be
>>>> time to "enhance" the VM to accommodate it.
>>>>     
>>>
>>> Oh, I'm sure there would.  The problem is that this bug is very
>>> subtle, and if it came back again it would be just as hard to
>>> diagnose.  If the change to use growable mappings were made upstream
>>> on some platform, would we notice?
>>>
>>>  
>>>>> Do you really think that the cost of get_stack_bounds() is 
>>>>> significant in
>>>>> the context of terminating a thread?
>>>>>       
>>>> It can be. This has introduced a new bottleneck on the thread
>>>> termination path and we're seeing that affect on certain systems (the
>>>> details of which I can't go in to).
>>>>     
>>>
>>> Aha, so this is not just a theoretical concern.  Fair enough.  It
>>> seems like I may have falsely assumed the work in the kernel to
>>> terminate a thread would be greater than this.
>>>
>>> Andrew.
>>>   
>>