RFR (S) cleanup misc issues prior to Contended Locking reorder and cache line bucket (8047104)

[Daniel D. Daugherty]

On 6/20/14 9:23 AM, Daniel D. Daugherty wrote:
>
>> src/share/vm/runtime/globals.hpp
>>
>> I wouldn't have classified the WorkAroundNPTLTimedWaitHang as 
>> unstable even though flagged as such. But this will be gone "soon" 
>> anyway.
>
> Since it was described as "unstable", I made it experimental. I'm
> planning to leave it as experimental until the other changeset
> removes it. Are you OK with that?

David, I haven't heard back on whether you're OK with leaving the
WorkAroundNPTLTimedWaitHang flag as experimental until it goes away.


>
>> 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