RFR (XS): Add necessary .inline.hpp files to fix non-PCH build

[Stefan Karlsson]

Thanks, Coleen.

This has now been pushed to hotspot-gc:
http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db8a7163c682

StefanK

On 12/11/12 10:52 PM, Coleen Phillimore wrote:
>
> This looks good to me.
> Coleen
>
> 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?
>>
>> StefanK
>>
>> On 2012-11-30 19:51, Volker Simonis wrote:
>>> Hi,
>>>
>>> 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
>>> "gc_implementation/shared/gcStats.cpp".
>>>
>>> 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,
>>> Volker
>>
>