RFR (XS): Add necessary .inline.hpp files to fix non-PCH build
stefan.karlsson at oracle.com
Thu Dec 13 10:28:04 PST 2012
This has now been pushed to hotspot-gc:
On 12/11/12 10:52 PM, Coleen Phillimore wrote:
> This looks good to me.
> On 12/06/2012 04:56 PM, Stefan Karlsson wrote:
>> Hi Volker,
>> Bug created: JDK-8004674
>> Thanks for fixing this. Your patch looks good. Though, I think it's
>> unfortunate that we have to add allocation.inline.hpp whenever this
>> 'new' is used.
>> Can someone who's an official Reviewer also review this?
>> On 2012-11-30 19:51, Volker Simonis wrote:
>>> I'm currently working on "6889002 : CHECK macros in return constructs
>>> lead to unreachable code" and just realized that the non-PCH build on
>>> Linux is broken (once again).
>>> The failure manifests itself with a "libjvm.so: undefined reference to
>>> `CHeapObj<(unsigned short)1280>::operator new(unsigned long, unsigned
>>> char*)'" which is caused by the recent "6995781: Native memory
>>> Tracking" change. The problem is that "operator new" is called in the
>>> files "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp"
>>> and "gc_implementation/shared/gcStats.cpp" for classes which have the
>>> template class "CHeapObj" as their base class. CHeapObj defines its
>>> own "new" operator in "memory/allocation.inline.hpp" but this
>>> inline.hpp file is not included into
>>> "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" and
>>> Funny enough, the problem doesn't seem to appear neither for older
>>> version of GCC (e.g. 4.4.6 on SLES 10) nor in debug builds. I could
>>> only reproduce it with a product build on Ubuntu 12.04 with GCC 4.6.3.
>>> The reason is most probably the fact that newer versions of GCC create
>>> template instantiations in a much more lazy way.
>>> The fix is easy - just add the missing includes to the corresponding
>>> files (see attached patch).
>>> Could somebody please open a bug for this issue and review/commit
>>> the change.
>>> Please notice that this actually not exactly the annoying "inline.hpp"
>>> problem which will be addressed with "8003990: Clean up inline
>>> #includes" but very similar because template definition and
>>> instantiation have similar semantics. This only didn't caused any
>>> problems until now because templates have been used very little in
>>> HotSpot. However once this changes, special care has to be taken to
>>> manage them in a way every compiler can cope with.
>>> Thank you and best regards,
More information about the hotspot-runtime-dev