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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Oct 1 15:41:16 UTC 2018

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 "classesdo()" member function of ClassLoaderData is declared as follows: void classesdo(void f(Klass*)); However, the definition of the member function in classLoaderData.cpp has a slightly different signature: void ClassLoaderData::classesdo(void f(Klass * const)) {..} Until now this worked with AIX because the call sites and the implementation of "ClassLoaderData::classesdo()" 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::classesdo()" 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