RFR(XXS)[12]: Different declaration and definition of ClassLoaderData::classes_do() leads to build failures
Volker Simonis
volker.simonis at gmail.com
Mon Oct 1 15:35:43 UTC 2018
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
More information about the hotspot-runtime-dev
mailing list