RFR: 8253717: Relocate stack overflow code out of thread.hpp/cpp [v3]

[Thomas Stuefe]

On Wed, 7 Oct 2020 14:41:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/stackOverflow.hpp line 121:
>> 
>>> 119:   //  (large addresses)
>>> 120:   //
>>> 121:
>> 
>> Nice ascii art :)
>> 
>> I wish though it could communicate better the openness of the ranges. E.g.:
>> 
>> +----------------+
>> |                |   <-- stack_end()
>> | red zone       |
>> |                |
>> +----------------+
>> |                |   <-- red_zone_base()
>> | yellow zone    |
>> |                |
>>      ....
>> |                |
>> +----------------+
>>                      <-- stack_base()
>> 
>> Maybe its just me but I always have to think a bit more here. With downward growing stacks normal range thinking is
>> reversed wrt to openness, so stack_base() points outside the stack and stack_end() is in the stack. This is true for
>> all base values - they point to locations outside the zone they base.  Maybe that is clear to all others but it
>> sometimes surprises me.
>
> I just found this comment.  I think the ascii art was added by @GoeLin.  I just moved it. Your picture is upside down
> but it sorta makes sense that the 'base' addresses point to the first address in the range, which is what I think they
> do.

I'm quite sure they don't.

stack_base() points to one-beyond-the-highest address in stack and therefore outside the stack. If the stack is 8
pages, stack_base points to the start of the 9th page. Therefore stack_base may actually point into a different memory
region, eg the stack of a neighboring thread, should they happen to be allocated without gap.

stack_red_zone_base() points to one-beyond-the-highest address in the red zone resp. the lowest address in the yellow
zone. So it points outside the red zone.

And so forth, for all other "base" values. All are one-beyond pointers.

But nothing that needs to be addressed with your patch, of course.

-------------

PR: https://git.openjdk.java.net/jdk/pull/522