RFC: Change C++ ABI so that interface dispatch does not depend on reflection.
Andrew Haley
aph@redhat.com
Wed Feb 1 11:23:00 GMT 2006
Per Bothner writes:
> Andrew Haley wrote:
> > Per Bothner writes:
> > >
> > > The direction I'm thinking is to split the Class object into
> > > (one or more) pointer tables, plus a pointer to a pointer-free
> > > descriptor in a separate read-only descriptor segment.
> >
> > We seem to be in danger of colliding!
>
> Hardly. I view my role here as suggesting things for *other* people
> to do ... I don't have time to actually implementing these ideas
> myself. My phrasing was ambiguous.
I see... :-)
> > My idea is to define a structure that that contains everything libgcj
> > needs to create an instance of Class.
>
> This structure is read-only and pointer-free? I'm guessing not,
> but hopefully the goal will be to move as much as possible
> into a separate read-only and pointer-free section.
It can be done in stages. To begin with, this structure will not be
pointer-free, because to do so would make the patch very complicated.
It'll simply be the fields of Class that are initialized by the
compiler.
> > For each class, an instance of
> > this structure is passed to libgcj by a static initializer. In turn,
> > libgcj returns a pointer to a newly created instance of Class. The
> > static initializer writes this to class$.
> >
> > This newly created class isn't initialized, so the creation can be
> > done fairly quickly.
>
> But you still eagerly (i.e. when the shared library is loaded, not
> when the class is accesses) create the Class object?
Yes. I think that's the right thing to do.
> Hopefully, you can (possibly as a follow-on) leave a lot of the data
> unexpanded in the original structure, where it can be accessed from
> the Class when needed.
Yes. We're looking in the same direction.
Andrew.
More information about the Java
mailing list