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

[Stefan Karlsson]

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