RFR (XXS): 8067865 : Changes 8066780/8066782 broke the non-PCH build

[Vladimir Kozlov]

Looks fine. Where do you want it to be pushed?

Thanks,
Vladimir

On 12/19/14 9:44 AM, Volker Simonis wrote:
> Hi,
>
> could somebody please have a quick look at this fix and sponsor it?
> It breaks our AIX build.
>
> Thank you and best regards,
> Volker
>
>
> On Thu, Dec 18, 2014 at 5:31 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> could sombody please review and sponsor this little change which fixes
>> the build on AIX after 8066780/8066782:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8067865
>> https://bugs.openjdk.java.net/browse/JDK-8067865
>>
>> Here's the full story: 8066780/8066782 did some code refactoring and
>> introduced the new files cardGeneration.{hpp,cpp,inline.hpp}.
>> Unfortunately, the changes forgot to include cardGeneration.inline.hpp
>> into tenuredGeneration.cpp and concurrentMarkSweepGeneration.cpp which
>> use the methods defined therein.
>>
>> This problem doesn't show up on Linux (even if build with
>> '--disable-precompiled-headers') because for some reason GCC places
>> weak references of the corresponding symbols in cardGeneration.o. So
>> later when linking libjvm.so the references can still be resolved. Sun
>> Studio also places global instantiations of the corresponding inline
>> functions into cardGeneration.o so we don't see any problems there as
>> well.
>>
>> xlC on AIX only puts a locally visible reference of the neede inline
>> functions into cardGeneration.o if he can't inline them (which is
>> perfectly legal because they are declared 'inline'). However, later
>> one during linking no globally visible versions of the corresponding
>> inline functions can be found and the link fails.
>>
>> The final fix is trivial - just include the corresponding
>> cardGeneration.inline.hpp file into the .cpp files which require its
>> method definitions.
>>
>> Thank you and best regards,
>> Volker