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

David Holmes david.holmes at oracle.com
Thu Jun 26 02:48:03 UTC 2014


On 26/06/2014 8:38 AM, Daniel D. Daugherty wrote:
> 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.

Yes that is fine - as I said it will be gone soon anyway.

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

Agreed.

Thanks,
David

>
> Dan
>
>


More information about the hotspot-runtime-dev mailing list