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

[Coleen Phillimore]

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?
David, are you going to make these changes?
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.
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100818/c5d10b1b/attachment.html