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
<[email protected]> 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<[email protected]> 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
<[email protected]> 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
