RFR: 8340491: Thread stack-base assertion should report which thread has the un-set stack [v3]

Stefan Karlsson stefank at openjdk.org
Mon Sep 30 08:48:35 UTC 2024


On Fri, 20 Sep 2024 06:49:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this simple enhancement to an assertion so we can identify which thread had the problem.
>> 
>> I had to move the function to the cpp file due to include file issues.
>> 
>> We are limited in what we can print due to this being used very early in the thread initialization process - in particular no ResourceMarks are possible so we can't print the name.
>> 
>> Testing:
>>  - tier 5 (used to debug [JDK-8340401](https://bugs.openjdk.org/browse/JDK-8340401))
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need ifdef ASSERT

This PR is much more complicated than it needs to be.

1) We would probably be fine with always having the implementation in the .cpp file. I don't think that we need to optimize away the call for this getter. I don't see hot code using this function.

2) If we really want to optimize it away, we can just stick the assert in the header just like we already do with related functions:


  bool is_in_stack_range(address adr, address limit, bool inclusive) const {
    assert(stack_base() > limit && limit >= stack_end(), "limit is outside of stack");
    return stack_base() > adr && (inclusive ? adr >= limit : adr > limit);
  }


There's no point in trying to separate the debug/release builds into .cpp/.hpp files if the related functions already put the assert in the header.

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

PR Comment: https://git.openjdk.org/jdk/pull/21102#issuecomment-2382487500


More information about the hotspot-runtime-dev mailing list