RFR(M): 8038498: Fix includes and C inlining after 8035330
goetz.lindenmaier at sap.com
Fri Mar 28 07:33:33 UTC 2014
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!
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.
On 28/03/2014 2:45 AM, Lindenmaier, Goetz wrote:
> Please review and test this change. I please need a sponsor:
> 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,
More information about the hotspot-dev