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

[Coleen Phillimore]

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
>