RFR(M): 8038498: Fix includes and C inlining after 8035330

[Lindenmaier, Goetz]

Hi,

yes, we would appreciate this a lot!
A pure hotspot build on a modern machine takes only a few minutes, 
this should be affordable I guess.

Thanks for the suggestion, David!

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Freitag, 28. März 2014 03:07
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Just as a general comment we should test with precompiled headers 
disabled as well.

David

On 28/03/2014 2:45 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review and test this change.  I please need a sponsor:
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>
> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
> broke the dbg build on AIX. That's because do_oop_partial_array() is added in
> a header, but requires inline function par_write_ref() through several inlined
> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
> as the corresponding inline header is not included.  The aix debug VM does not start.
>
> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.
>
> Unfortunately this now causes a cyclic dependency that breaks the linux build.
> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
> can not see the class declaration.
> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
> But .inline.hpp files never should be included in .hpp files.
>
> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
> I had to move a row of functions to existing .inline.hpp files.
>
> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>
> Best regards,
>    Goetz
>