Request for approval: 6929067: Stack guard pages should be removed when thread is detached
David.Holmes at oracle.com
Wed Aug 18 16:41:51 PDT 2010
Andrew Haley said the following on 08/17/10 18:14:
> 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?
I would hope (and I know hopes can be dashed) that the upstream
maintainers would not make such a change silently.
Was there a regression test created for this bug? That would catch any
>>> 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.
More information about the hotspot-dev