RFR: 8075247: Cleanup specialized_oop_closures.hpp

[Stefan Karlsson]

Hi,

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
>>>> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro.
>>>>
>>>> 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,
StefanK

>
> Thanks,
>    Thomas
>
>