Missing/wrong build dependencies for inline functions in HotSpot
Volker Simonis
volker.simonis at gmail.com
Mon Jun 11 09:33:29 PDT 2012
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
More information about the hotspot-dev
mailing list