RFR: 8329757: Crash with fatal error: DEBUG MESSAGE: Fast Unlock lock on stack [v2]

[Axel Boldt-Christmas]

On Thu, 11 Apr 2024 03:25:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Drop includes
>>  - Strengthen waiting_monitor assert
>>  - Add explicit break
>
> src/hotspot/share/runtime/deoptimization.cpp line 72:
> 
>> 70: #include "runtime/fieldDescriptor.inline.hpp"
>> 71: #include "runtime/frame.inline.hpp"
>> 72: #include "runtime/globals.hpp"
> 
> Is this extra include needed?

Not with the current state of the codebase. Currently we get  `"utilities/globalDefinitions.hpp"` and `"runtime/globals.hpp"` via the following include chains:

#include "classfile/javaClasses.inline.hpp"
  #include "classfile/javaClasses.hpp"
    #include "classfile/vmClasses.hpp"
      #include "classfile/vmClassID.hpp"
        #include "utilities/enumIterator.hpp"
          #include "metaprogramming/primitiveConversions.hpp"
            #include "utilities/globalDefinitions.hpp"
    #include "runtime/handles.hpp"
      #include "memory/arena.hpp"
        #include "runtime/globals.hpp"


But in general, especially for `.cpp` files, I like to include directly what is used (except for system headers like `cstdint` and `cstddef` for which I include `utilities/globalDefinitions.hpp`). All this is to have removals elsewhere not break the includes (it can obviously still break things due to updated include order if we do nasty things with the preprocessor etc.)

However I know that there is sometimes pushback on both `globals.hpp` and `globalDefinitions.hpp` because for almost any non-trivial compilation unit (that is not utility code) they will get included from some of its leaf dependencies. 

I'll drop these includes in this PR. But that is my rational for including them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18715#discussion_r1560454775