Linux current_stack_region()

[David Holmes - Sun Microsystems]

Hi Gary,

Disclaimer: this isn't code I've worked with - though I did review the 
most recent changes - and stack management is a particularly confusing 
area. :)

Gary Benson said the following on 11/03/08 01:06 AM:
> The first thing I discovered is that the current linux code is wrong
> when there are guard pages.  The comment above current_stack_region
> in os_linux_{i486,amd64,x86}.cpp puts the guard page outside the
> region reported by pthread_attr_getstack(), which is not the case.

Reading the POSIX specification I don't see anything that explicitly 
states this, but I would infer that the guard pages are not part of the 
region reported by pthread_attr_getstack from the statement:

"The stack attributes specify the area of storage to be used for the 
created thread's stack."

i.e. getstack reports the _usable_ stack for the thread. Hence any guard 
region is outside that.

> I started modifying current_stack_region to do just that, but its
> comments contain warnings that pthread_getattr_np() returns bogus
> values for initial threads.  os::Linux::capture_initial_stack()
> has more such warnings, though neither mentions exactly _what_ was
> bogus.  Does anyone know?  Without a working pthread_getattr_np()
> you can't use pthread_attr_getguardsize(), and without that it's
> not possible to implement current_stack_region() in the form it's
> currently defined.

The comment re pthread_getattr_np is about 5 years old and I couldn't 
find anything more specific than the inference that they discovered that 
it returned the wrong values on the initial thread on the distributions 
of the day (whatever they may have been). Hotspot is full of this kind 
of historical baggage with workarounds for a range of now defunct linux 
systems (and old Solaris versions too).


Cheers,
David Holmes