RFR(XXS)[12]: Different declaration and definition of ClassLoaderData::classes_do() leads to build failures

[coleen.phillimore at oracle.com]

Looks good.  Yes definitely trivial.
Thanks,
Coleen

On 10/1/18 11:35 AM, Volker Simonis wrote:
> Hi,
>
> can I please have a review for this tiny and trivial fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211328/
> https://bugs.openjdk.java.net/browse/JDK-8211328
>
> 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.
>
> Thank you and best regards,
> Volker