src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp

rev 8517 : 8078513: [linux]  Clean up code relevant to LinuxThreads implementation
Reviewed-by: dholmes, sla, coleenp

*** 1,7 ****
  /*
!  * Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.
--- 1,7 ----
  /*
!  * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.
*** 38,49 ****
  // Notice that _sp_map is allocated in the bss segment, which is ZFOD
  // (zero-fill-on-demand). While it reserves 4M address space upfront,
  // actual memory pages are committed on demand.
  //
  // If an application creates and destroys a lot of threads, usually the
! // stack space freed by a thread will soon get reused by new thread
! // (this is especially true in NPTL or LinuxThreads in fixed-stack mode).
  // No memory page in _sp_map is wasted.
  //
  // However, it's still possible that we might end up populating &
  // committing a large fraction of the 4M table over time, but the actual
  // amount of live data in the table could be quite small. The max wastage
--- 38,48 ----
  // Notice that _sp_map is allocated in the bss segment, which is ZFOD
  // (zero-fill-on-demand). While it reserves 4M address space upfront,
  // actual memory pages are committed on demand.
  //
  // If an application creates and destroys a lot of threads, usually the
! // stack space freed by a thread will soon get reused by new thread.
  // No memory page in _sp_map is wasted.
  //
  // However, it's still possible that we might end up populating &
  // committing a large fraction of the 4M table over time, but the actual
  // amount of live data in the table could be quite small. The max wastage