RFR: 8074319: barrier_set_cast defined via friend injection

[Kim Barrett]

On Mar 3, 2015, at 12:55 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I was looking at the same problem today because it also fails on AIX
> with xlC 12.1.
> 
> I'm not one hundred percent sure but I currently more tend to say it
> is a compiler bug although I'll have to dive deeper into the C++
> standard before I can give a qualified answer here.

The relevant standardese, from C++03 7.3.1.2, is

  If a <tt>friend</tt> declaration in a non-local class first declares
  a class or function (footnote 83: this implies that the name of the
  class or function is unqualified) the friend class or function is a
  member of the innermost enclosing namespace.  The name of the friend
  is not found by simple name lookup until a matching declaration is
  provided in that namespace scope (either before or after the class
  declaration granting friendship).

> But your change looks good and it also works on AIX. So if you like,
> you can consider it reviewed.

Thanks.

> However, with your change "barrier_set_cast()" won't be an inline
> function any more which may have performance impacts (this is
> something you'll have to judge).

The definition moved to namespace scope in the webrev I posted is
declared inline.

> I'd like to propose a similar change which keeps "barrier_set_cast()"
> as inline function and still works with Xcode5 and xlC 12 on AIX:
> 
> diff -r 71f4ed3c627f src/share/vm/memory/barrierSet.hpp
> --- a/src/share/vm/memory/barrierSet.hpp        Tue Mar 03 13:25:23 2015 +0000
> +++ b/src/share/vm/memory/barrierSet.hpp        Tue Mar 03 18:51:47 2015 +0100
> @@ -32,6 +32,10 @@
> // This class provides the interface between a barrier implementation and
> // the rest of the system.
> 
> +class BarrierSet;
> +template<typename T>
> +T* barrier_set_cast(BarrierSet* bs);
> +
> class BarrierSet: public CHeapObj<mtGC> {
>   friend class VMStructs;
> public:

This doesn’t have an inline storage class specifier.

> PS: I'm a little bit confused that this error hasn't been catched by
> JPRT because the OpenJDK Wiki
> (https://wiki.openjdk.java.net/display/Build/Supported+build+platforms)
> lists clang 5.1 as official build platform for MacOS X?

Maybe the JPRT farm is still lagging?