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

Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Oct 1 15:39:53 UTC 2018

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/

     No comments.

Thumbs up.


> 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

More information about the hotspot-runtime-dev mailing list