Missing/wrong build dependencies for inline functions in HotSpot

[Keith McGuigan]

Looks good to me.  Needs just one more reviewer and then I'll get it moving.

On 6/11/2012 12:33 PM, Volker Simonis wrote:
> Thank you!
>
> I've just posted a webrev on the list.
> Please be so kind to review and push it.
>
> Regards,
> Volker
>
> On Mon, Jun 11, 2012 at 3:49 PM, Keith McGuigan
> <keith.mcguigan at oracle.com>  wrote:
>>
>> Here's the bug number: 7175914
>>
>> --
>> - Keith
>>
>>
>> On 6/11/2012 9:21 AM, Coleen Phillimore wrote:
>>>
>>>
>>> Thank you for finding this problem and this change! It's been annoying
>>> me lately but no time to figure it out. I don't think there is a bug for
>>> it yet. I think you should prepare it against this and I'll push it
>>> (after review).
>>>
>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot
>>>
>>> Thanks again!
>>> Coleen
>>>
>>> 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