Missing/wrong build dependencies for inline functions in HotSpot

[Coleen Phillimore]

Thanks Keith.
Coleen

On 6/11/2012 7:14 AM, Keith McGuigan wrote:
>
> I can shepherd this through the hotspot-rt repository, where it will 
> filter up to hotspot-main and then jdk8/hotspot.  I'll make a CR for 
> this too.
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot
>
> -- 
> - Keith
>
> On 6/11/2012 6:10 AM, Volker Simonis wrote:
>> Should this change be against
>> http://hg.openjdk.java.net/jdk8/build/hotspot or better for
>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot?
>>
>> On Mon, Jun 11, 2012 at 12:01 PM, Volker Simonis
>> <volker.simonis at gmail.com>  wrote:
>>> I found the problem!
>>>
>>> It's related to the use of precompiled headers. We need to use
>>> '-fpch-deps' in order to get the full dependencies, otherwise all the
>>> dependencies from the pch file are omitted.
>>>
>>> I'm currently preparing a webrev which fixes  the problem. It would be
>>> nice if somebody could meanwhile open a bug for the problem (e.g.
>>> "Usage of gcc with precompiled headers produces wrong build
>>> dependencies") and provide a bug-id.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Fri, Jun 8, 2012 at 7:50 PM, Volker 
>>> Simonis<volker.simonis at gmail.com>  wrote:
>>>> Yes, that's really strange. You're right, the dependency file should
>>>> contain ".. the names of all the included files" (gcc -man page).
>>>>
>>>> So it seems to be a bug in gcc and how it handles '-MMD' although I
>>>> couldn't find a bug report for it and I can't believe that nobody else
>>>> has noticed this before. I've tried gcc 4.4.3 and 4.1.2 and they both
>>>> produce a wrong dependency file which only contains the direct
>>>> includes of the processed .cpp file (with "-c -MMD -MP -MF
>>>> ../generated/dependencies/frame.o.d -o frame.o").
>>>>
>>>> If I compile with "-c -MM -MP -MF ../generated/dependencies/frame.o.d
>>>> -o frame.o" the generated dependency file is much bigger and looks ok,
>>>> but of course I get no object file. I also get he same wrong behavior
>>>> for -MD vs -M. The only reason behind -MD and -MMD is that it "..can
>>>> be used to generate a dependency output file as a side-effect of the
>>>> compilation process" (from the GCC man page) - but that doesn't seem
>>>> to work..
>>>>
>>>> Does anybody has an explanation for this behavior?
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>> On Fri, Jun 8, 2012 at 6:25 PM, Keith McGuigan
>>>> <keith.mcguigan at oracle.com>  wrote:
>>>>>
>>>>> I don't understand why gcc doesn't put frame_x86.inline.hpp into the
>>>>> generated/dependencies/frame.o.d file.  Isn't the point of -MMD to 
>>>>> calculate
>>>>> the full closer of header files used for listing as a dependency?  
>>>>> Is this a
>>>>> bug in gcc or are we using it wrong?
>>>>>
>>>>> I notice that Sun Studio compiler does put the arch-specific 
>>>>> header file in
>>>>> the generated dependency file.  Weird.
>>>>>
>>>>> -- 
>>>>> - Keith
>>>>>
>>>>>
>>>>> On 6/8/2012 11:58 AM, Volker Simonis wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've just stumbled across the problem that changing the 
>>>>>> implementation
>>>>>> of an inline function in HotSpot does not necessarily rebuild all 
>>>>>> the
>>>>>> call sites of that function. This is because because of the way how
>>>>>> the build dependencies are handled within the HotSpot. As an example
>>>>>> you may have a look at frame.cpp:
>>>>>>
>>>>>> frame.cpp includes frame.inline.hpp
>>>>>> frame.inline.hpp includes frame_x86.inline.hpp
>>>>>>
>>>>>> However frame.cpp only depends on frame.inline.hpp directly (i.e.
>>>>>> frame.cpp only includes frame.inline.hpp directly and this is where
>>>>>> the dependencies generated by gcc with '-MMD' are computed from).
>>>>>> So if an inline function in frame_x86.inline.hpp will be changed 
>>>>>> (e.g.
>>>>>> the constructor frame::frame()), frame.cpp will not be recompiled in
>>>>>> an incremental build, although it uses the constructor 
>>>>>> frame::frame().
>>>>>> This makes incremental builds useless (or dangerous, depending on 
>>>>>> the
>>>>>> view point) when inline functions are changed.
>>>>>>
>>>>>> I think this is a non-trivial problem which is deeply rooted in the
>>>>>> way how C++ implements inlining and the way how inline functions are
>>>>>> defined in HotSpot (i.e. .hpp, .inline.hpp,  _<cpu>.hpp and
>>>>>> _<cpu>.inline.hpp files). I don't have a solution for it but just
>>>>>> wanted to ask if somebody else already stumbled upon this problem
>>>>>> and/or has solution for it?
>>>>>>
>>>>>> Regards,
>>>>>> Volker