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 17:11:45 UTC 2018


Thanks Coleen and Dan for the quick reviews!

On Mon, Oct 1, 2018 at 5:41 PM <coleen.phillimore at oracle.com> wrote:
>
>
> 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
>


More information about the hotspot-runtime-dev mailing list