RFR (XS) 8221726: Multiple build failures after JDK-8221698 (Remove redundant includes from popular header files)

[Ioi Lam]

Hi Aleksey, thanks for fixing this!

Now I realized that the hotspot header file dependency is more fragile 
than I thought.

Thomas, I have a couple more changesets for cleaning header files. I'll 
post them and let people try them out on other ports (for at least a 
week, etc) before pushing. I'll also test on more combinations like zero 
and minimal.

I'll try to write a tool to analyze how the header files are included. 
The current state is pretty abysmal (from a simple script that I wrote):

http://cr.openjdk.java.net/~iklam/jdk13/headers.txt

Number of headers       =   1293
Number of objs          =    942
Each obj file includes  =    279.64 headers
Each header is included =    203.73 times
Rank  1% -  10% headers are included    1.7 times
Rank 11% -  20% headers are included    3.0 times
Rank 21% -  30% headers are included    5.2 times
Rank 31% -  40% headers are included   10.6 times
Rank 41% -  50% headers are included   21.4 times
Rank 51% -  60% headers are included   42.7 times
Rank 61% -  70% headers are included   97.4 times
Rank 71% -  80% headers are included  281.1 times
Rank 81% -  90% headers are included  711.8 times
Rank 91% - 100% headers are included  866.2 times

So basically you have 20% of headers that are practically included in 
every object file :-(


Thanks
- Ioi


On 3/31/19 9:37 PM, Thomas Stüfe wrote:
> On Mon 1. Apr 2019 at 00:19, David Holmes <david.holmes at oracle.com> wrote:
>
>> Hi Aleksey,
>>
>> On 1/04/2019 8:04 am, Aleksey Shipilev wrote:
>>> Bug:
>>>     https://bugs.openjdk.java.net/browse/JDK-8221726
>>>
>>> See bug for examples of build failures. Seems only ppc64le and x86_64
>> {minimal, zero} are affected.
>>> Happy to fold other fixes if other platforms are failing too.
>>>
>>> Fix:
>>>
>>> diff -r 7ad62bdfec59
>> src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp
>>> --- a/src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp Sun Mar
>> 31 23:29:47 2019 +0200
>>> +++ b/src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp Sun Mar
>> 31 23:52:49 2019 +0200
>>> @@ -28,4 +28,5 @@
>>>    #include "gc/shared/barrierSetAssembler.hpp"
>>>    #include "interpreter/interp_masm.hpp"
>>> +#include "runtime/jniHandles.hpp"
>>>
>>>    #define __ masm->
>>> diff -r 7ad62bdfec59 src/hotspot/share/classfile/systemDictionary.hpp
>>> --- a/src/hotspot/share/classfile/systemDictionary.hpp  Sun Mar 31
>> 23:29:47 2019 +0200
>>> +++ b/src/hotspot/share/classfile/systemDictionary.hpp  Sun Mar 31
>> 23:52:49 2019 +0200
>>> @@ -31,4 +31,5 @@
>>>    #include "oops/symbol.hpp"
>>>    #include "runtime/java.hpp"
>>> +#include "runtime/mutexLocker.hpp"
>>>    #include "runtime/reflectionUtils.hpp"
>>>    #include "runtime/signature.hpp"
>> I'm struggling to see what changes in JDK-8221698 led to these problems,
>> but the fixes certainly look totally appropriate. I also think this
>> constitutes a trivial change and can be pushed with one Review andnot
>> wait 24 hours. (If there are any issues I'll sort them out if needed.)
>>
>> Aside: are there any tools that will show where a particular declaration
>> is being included from? We've obviously got some interesting transitive
>> closures with conditional includes.
>>
> I think it would be helpful if we could have at least one zero build (eg
> x64) in jdk-submit.
>
> ..thomas
>
>
>> Thanks,
>> David
>>
>>> Testing: Linux x86_64 {server, minimal, zero}, ppc64le builds
>>>
>>> Thanks,
>>> -Aleksey
>>>