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

[David Holmes]

Hi Coleen,

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.

> 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.
>>   
>