RFR(S): 8151593: Cleanup definition/usage of INLINE/NOINLINE macros and add xlC support

[Daniel D. Daugherty]

Hi Volker,

The objectMonitor.cpp and synchronizer.cpp NOINLINE issue is tracked via:

JDK-8049103 investigate whether inlining still needs to be inhibited in
             objectMonitor.cpp and synchronizer.cpp
https://bugs.openjdk.java.net/browse/JDK-8049103

Feel free use both bug IDs in your changeset.

Dan


On 3/10/16 10:10 AM, Volker Simonis wrote:
> Hi,
>
> can I please have a review and a sponsor for the following clean-up change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8151593/
> https://bugs.openjdk.java.net/browse/JDK-8151593
>
> First I only wanted to implement the INLINE macro for xlC in
> instanceKlass.inline.hpp. But then I realized that we also define
> NOINLINE in various other files so I decided to do it "the right way"
> and clean up the code a little bit.
>
> I've now moved the definition of the INLINE/NOINLINE macros to
> globalDefinitions_<compiler>.hpp. In the case where there is no
> compiler-specific definition, globalDefinitions.hpp defines empty
> defaults for the macros.
>
> I've also renamed INLINE to ALWAYSINLINE to match its intention more clearly.
>
> Currently NOINLINE is really only defined on Linux. This is the same
> behavior we had before the change. Following some more details:
>
> os_linux.cpp
>
> - removed the handling for gcc < 3 (even we at SAP don't use this anymore :)
>
> objectMonitor.cpp, synchronizer.cpp
>
> - completely removed the annotation with NOINLNE which is there since
> pre-OpenJDK times already. The comment mentions that this was required
> to prevent build-time failures with 'older' versions of GCC. But we
> already build without 'NOINLINE' on Linux/ppc64 since years and I've
> also tested that it still works on Linux/x86.
>
> I've Build and smoke-tested on Linux/amd64 and Linux/ppc64,
> Solaris/SPARC, MacOS X, AIX and Windows.
>
> Regards,
> Volker