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