RFC: Change C++ ABI so that interface dispatch does not depend on reflection.
Per Bothner
per@bothner.com
Tue Jan 31 22:38:00 GMT 2006
David Daney wrote:
> Here is an idea: Place the method reflection data at a fixed offset
> from the beginning of each corresponding method (perhaps -8), then the
> vtable also serves as the reflection table.
This may hurt locality - one would prefer reflection to go in a
separate section - normally not mapped in or at least in separate
cache lines.
Also, note that with the new (non-C++) ABI the vtables are generated
at run-time (class initialization time, presumably).
> For private methods there would have to be a separate faux-vtable so
> that they could be reflected on as well.
And static methods.
> Access from the name from reflection data would be encoded as an offset
> from the method entry point so that there would be no runtime relocation
> needed.
This may make sharing of names difficult. Though one can shares names
without relocation within a single generated object file if the names
are in the same section as the text.
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.
The actual field and method descriptors are in the same descriptor
segment, as are there names. The name of a field or method would
be gived by a constant relative offset. Offsets and other constants
are encoded using a variable-sized encoding. Fields of a class are
just encoded consequtively; likewise methods. Multiple classes that
are compiled together generate a common descritor segment, thus allowing
sharing of names and other constant data.
Encoding types (of fields, methods, supertypes etc) can be done
different ways. One way is to use a textual encoding, as is done
in .class files. Another is using an index in the Class's pointer
table. A possibility that a type is an offset into the descriptor
table, where we encode a type descriptor. (If a type is a class
using the same descriptor segment, just use the class descriptor.)
Refernces to classes in other segments may need some indirection
mechanism.
java.lang.reflect.Method and Field objects are created lazily. They
may contain a pointer into the descriptor table. No need to actually
create the names: when searching for a field or method by name, we
match the given String against the compressed/encoded data in the
descriptor table, and on a match use the supplied String. We do
have to allocate a new String if getName is called on a Field or
Method which doesn't have a name stored.
--
--Per Bothner
per@bothner.com http://per.bothner.com/
More information about the Java
mailing list