RFR: 8257731: Remove excessive include of stubRoutines.hpp

Ioi Lam ioi.lam at oracle.com
Sun Dec 6 18:59:14 UTC 2020



On 12/6/20 9:44 AM, Aleksey Shipilev wrote:
> On Sat, 5 Dec 2020 11:29:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>
>>>> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository.
>>> OK, I'll push in JDK 17.
>>> With sufficient pre-integration testing this should not be an issue. It
>>> seems for JDK-8257563 no GitHub actions were run and so numerous build
>>> variants were missed.
>> And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts.

Just to be clear -- this is not a "disruptive" commit. It's unlikely to 
cause problems when backporting unrelated commits from the mainline back 
to JDK 16.

This commit discovers existing problems in the HotSpot code -- many 
source files do not explicitly include header files for the APIs they 
reference. Instead, they rely on another header file (sometimes many 
recursions away) to include the required header files. For example:

c1_LIRAssembler_aarch64.cpp calls StubRoutines::generic_arraycopy(). 
However, it didn't explicitly include stubRoutines.hpp, but relied on 
thread.hpp to do that. After stubRoutines.hpp is removed from 
thread.hpp, c1_LIRAssembler_aarch64.cpp fails to compile.

So the majority of the the changes in this commit is *adding* #includes 
in the CPP files. This by definition can only cause FEWER build failures 
if this commit is pushed into JDK 16.

Conversely, if this commit is not pushed in JDK 16, I can imagine in 
some edge scenarios that  an unrelated backport into 16 cannot be 
cleanly applied. But this will require a second backport that *removes* 
headers from an HPP file (which will be unlikely to be backported in the 
first place). In any case, even if this happens, any breakage can be 
easily fixed by adding #includes in the backport, and we have such 
backports from time to time anyway.

So in my opinion, it doesn't really matter if this commit is in JDK 16 
or not.

> I don't mind pushing it for JDK 16. I was just suggesting that we defer somewhat intrusive cleanups to JDK 17, as it customary to do (at least in my vicinity) in order to have everyone else build/test based on clean master in the days coming to JDK 16 cutoff. But we could instead pay more attention to the state of master and fix the follow-up build failure bugs even more promptly this week.
>

I agree with this. In the event this commit breaks something in a build 
that I haven't tested, a follow-up commit needs to be pushed. It would 
be nice to push this commit after the cutoff to avoid the need to 
backport the follow-up commit.

Thanks
- Ioi


More information about the hotspot-dev mailing list