RFR: 8325517: Shenandoah: Reduce unnecessary includes from shenandoahControlThread.cpp

Aleksey Shipilev shade at openjdk.org
Thu Feb 8 18:48:55 UTC 2024


On Thu, 8 Feb 2024 18:32:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The control thread used to run much more of the cycle directly. This code was all factored out into different classes, but many of the vestigial headers remained. Removing these improves compilation times and makes maintenance easier.

Looks generally okay. The usual rule of thumb is to see if any symbols from the include are actually used in the compilation unit. If used, keep the explicit header. Check this? At least one case is obvious from reading the code, see below.

Note that build might still succeed without the explicit header due to transitive header dependencies, but it is fragile and would yield build failures later.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 47:

> 45: #include "memory/metaspaceStats.hpp"
> 46: #include "memory/universe.hpp"
> 47: #include "runtime/atomic.hpp"

`Atomic` is directly used, so the include should be left here.

src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 46:

> 44: 
> 45: 
> 46: enum StringDedupMode {

I think the only use is in `ShenandoahMark`, right? Therefore, this declaration should go to `shenandoahMark.hpp`, so we do not have to include `shenandoahUtils.hpp` there?

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

PR Review: https://git.openjdk.org/jdk/pull/17778#pullrequestreview-1870981172
PR Review Comment: https://git.openjdk.org/jdk/pull/17778#discussion_r1483430902
PR Review Comment: https://git.openjdk.org/jdk/pull/17778#discussion_r1483428174


More information about the shenandoah-dev mailing list