The following issue came up during the code review cycle for the following:

JDK-8047104 cleanup misc issues prior to Contended Locking
                reorder and cache line bucket

Both objectMonitor.cpp and synchronizer.cpp contain:

#if defined(__GNUC__) && !defined(IA64) && !defined(PPC64)
  // Need to inhibit inlining for older versions of GCC to avoid build-time failures
  #define NOINLINE __attribute__((noinline))
#else
  #define NOINLINE
#endif

and it would be good to determine if this is still needed.


>> src/share/vm/runtime/objectMonitor.cpp
>>
>> Wondering if "Need to inhibit inlining for older versions of GCC to avoid build-time failures" is actually still relevant? Something for a later set of changes.
>
> Good question. I'll chase down the history on that one and try
> to narrow down the GCC era/version where this used to happen.
> Will probably result in a new follow up bug to propose removal
> of the inhibit inlining stuff.

Had to chase this back into the TeamWare history:

$ sgv src/share/vm/runtime/synchronizer.cpp | grep noinline
1.119
1.69.1.6          #define ATTR __attribute__((noinline))
4716 lines
No id keywords (cm7)

$ sp -r1.69.1.6 src/share/vm/runtime/synchronizer.cpp
src/share/vm/runtime/SCCS/s.synchronizer.cpp:

D 1.69.1.6 05/08/16 17:22:05 dice 150 149       00267/00163/03862
MRs:
COMMENTS:

$ sccs sccsdiff -r1.69.1.{5,6} src/share/vm/runtime/synchronizer.cpp | head
11a12,18
> #if defined(__GNUC__)
>   // Need to inhibit inlining for older versions of GCC to avoid build-time failures
>   #define ATTR __attribute__((noinline))
> #else
>   #define ATTR
> #endif
>

so the noinline stuff was committed (sccs delget) back on
August 16, 2005 in a delta without any bug ID. Sigh.

The first release that contains that delta is JDK1.6.0 so
here's the Linux compilers in use back then:

$ strings linux-i586/jre/lib/i386/client/libjvm.so | grep 'with gcc'
Java HotSpot(TM) Client VM (1.6.0-b105) for linux-x86, built on Nov 29 2006 01:24:38 by "java_re" with gcc 3.2.1-7a (J2SE release)

$ strings linux-amd64/jre/lib/amd64/server/libjvm.so | grep 'with gcc'
Java HotSpot(TM) 64-Bit Server VM (1.6.0-b105) for linux-amd64, built on Nov 29 2006 01:44:03 by "uucp" with gcc 3.2.2 (SuSE Linux)


In contrast, for JDK8 we used the following on Linux:

$ strings linux-i586/jre/lib/i386/client/libjvm.so | grep 'with gcc'
Java HotSpot(TM) Client VM (25.0-b70) for linux-x86 JRE (1.8.0-b132), built on Mar  4 2014 03:27:19 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)

$ strings linux-x64/jre/lib/amd64/server/libjvm.so | grep 'with gcc'
Java HotSpot(TM) 64-Bit Server VM (25.0-b70) for linux-amd64 JRE (1.8.0-b132), built on Mar  4 2014 03:07:25 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)


And in JDK9, we're using the following on Linux:

$ strings linux-i586/jre/lib/i386/client/libjvm.so | grep 'with gcc'
Java HotSpot(TM) Client VM (1.9.0-ea-b19) for linux-x86 JRE (1.9.0-ea-b19), built on Jun 19 2014 00:08:12 by "java_re" with gcc 4.8.2

$ strings linux-x64/jre/lib/amd64/server/libjvm.so | grep 'with gcc'
Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b19) for linux-amd64 JRE (1.9.0-ea-b19), built on Jun 18 2014 23:57:36 by "java_re" with gcc 4.8.2

So I'm thinking that I need to roll this historical info into a
new bug for someone to investigate whether to remove the noinline
stuff. Agreed?

Dan