RFR: 8075247: Cleanup specialized_oop_closures.hpp

Stefan Karlsson stefan.karlsson at oracle.com
Tue Mar 17 13:25:12 UTC 2015


On 2015-03-17 14:20, Thomas Schatzl wrote:
> Hi,
> On Mon, 2015-03-16 at 22:12 +0100, Stefan Karlsson wrote:
>> Hi Thomas,
>> On 2015-03-16 21:45, Thomas Schatzl wrote:
>>> Hi,
>>> On Mon, 2015-03-16 at 17:04 +0100, Stefan Karlsson wrote:
>>>> Hi,
>>>> Please review this patch to rename and simplify some macros in
>>>> specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp.
>>>> The patch contains the following changes:
>>>> 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have
>>>> been renamed into SPECIALIZED_*G1.
>>>> 2) Removed some unnecessary #ifdefs. The compile will catch the error if
>>>> we try to redefine the macro.
>>>> 3) Gather all CMS specific macros inside a new
>>>> http://cr.openjdk.java.net/~stefank/8075247/webrev.01
>>>> https://bugs.openjdk.java.net/browse/JDK-8075247
>>> I am not completely sure why in many files touched in this change both
>>> cpp and the corresponding hpp files include
>>> specialized_oop_closures.hpp. Is there a particular reason to do so?
>> Yes. All files should, preferably, explicitly include the files that
>> they rely on. Sometimes, that's not done and the dependency is
>> resolved via the transitive closure of the include files, but relying
>> on that gives us a more fragile include hierarchy where seemingly
>> unrelated changes cause compile errors when includes are
>> changed/removed.
> Okay - I was not aware that this should also be the case for includes by
> the header file corresponding to the given cpp file.
> Btw, do you know of a tool to find out missing includes (or just find
> ones only included transitively)?

No, I don't know of any tool that will do it for you automatically.

I sometimes use 'g++ -H' to look at the included hierarchy:

$ man g++
        -H  Print the name of each header file used, in addition to 
other normal activities.  Each name is indented to show how deep in the 
#include stack it is.  Precompiled header files are also printed, even 
if they are found to be
            invalid; an invalid precompiled header file is printed with 
...x and a valid one with ...! .

The eclipse Include Browser can also be used too look at the includes.

> Looks good.


> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list