Linux current_stack_region()

[David Holmes - Sun Microsystems]

Note also that pthread_attr_setguardsize may internally round-up the 
guardsize to a multiple of page-size; but pthread_attr_getguardsize 
returns the original supplied value not the rounded one. So you would 
have a problem trying to adjust for the true guardsize in a portable way.

David

David Holmes - Sun Microsystems said the following on 11/03/08 10:34 AM:
> 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