Change JDK-8209645 "Split ClassLoaderData and ClassLoaderDataGraph into separate files" extracted the ClassLoaderDataGraph class and its associated members from classLoaderData.cpp into classLoaderDataGraph.cpp.

On AIX with its picky XLC compiler this revealed a long standing bug which now leads to a build failure:

In classLoaderData.hpp the "classes_do()" member function of ClassLoaderData is declared as follows:

void classes_do(void f(Klass*));

However, the definition of the member function in classLoaderData.cpp has a slightly different signature:

void ClassLoaderData::classes_do(void f(Klass * const)) {..}

Until now this worked with AIX because the call sites and the implementation of "ClassLoaderData::classes_do()" were in the same compilation unit and the meber function was apparently inlined which seemed to work.

After the call sites have now been factored out into their own compilation unit, they expect to find a version of "ClassLoaderData::classes_do()" which takes an argument of type "void f(Klass*)" but can only find one which takes an argument of type "void f(Klass * const)" which it considers to be of different type.

I'm not sure if this is a bug in XLC, but I think that declaring and defining a member function with different signature makes no sense, so we should fix this. Especially, because the fix is trivial:

diff -r bd8ea10dfdae src/hotspot/share/classfile/classLoaderData.hpp
--- a/src/hotspot/share/classfile/classLoaderData.hpp Mon Oct 01 10:01:11 2018 +0200
+++ b/src/hotspot/share/classfile/classLoaderData.hpp Mon Oct 01 17:01:01 2018 +0200
@@ -183,7 +183,7 @@
   bool keep_alive() const { return _keep_alive > 0; }
 
   oop holder_phantom() const;
- void classes_do(void f(Klass*));
+ void classes_do(void f(Klass* const));
   void loaded_classes_do(KlassClosure* klass_closure);
   void classes_do(void f(InstanceKlass*));
   void methods_do(void f(Method*));