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

Andrew Haley aph at redhat.com
Fri Aug 20 01:34:29 PDT 2010


On 08/19/2010 04:49 AM, David Holmes wrote:

> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp
> --- a/src/os/linux/vm/os_linux.cpp
> +++ b/src/os/linux/vm/os_linux.cpp
> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint
>  // where we're going to put our guard pages, truncate the mapping at
>  // that point by munmap()ping it.  This ensures that when we later
>  // munmap() the guard pages we don't leave a hole in the stack
> -// mapping.
> +// mapping. This only affects the main/initial thread, but guard
> +// against future OS changes
>  bool os::create_stack_guard_pages(char* addr, size_t size) {
>    uintptr_t stack_extent, stack_base;
> -  if (get_stack_bounds(&stack_extent, &stack_base)) {
> +  if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) {
> +      assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread");
>      if (stack_extent < (uintptr_t)addr)
>        ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent);
>    }

Is stack_extent initialized here in NOT_DEBUG mode?

> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char*
>  }
> 
>  // If this is a growable mapping, remove the guard pages entirely by
> -// munmap()ping them.  If not, just call uncommit_memory().
> +// munmap()ping them.  If not, just call uncommit_memory(). This only
> +// affects the main/initial thread, but guard against future OS changes
>  bool os::remove_stack_guard_pages(char* addr, size_t size) {
>    uintptr_t stack_extent, stack_base;
> -  if (get_stack_bounds(&stack_extent, &stack_base)) {
> +  if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) {
> +      assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread");
> +
>      return ::munmap(addr, size) == 0;
>    } 

This is basically a good compromise, I think.

Andrew.


More information about the hotspot-dev mailing list