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