binary metadata

Thu Sep 30 16:11:00 GMT 2004

Jakob Praher wrote:
>>We already have object file metadata which is used by the runtime 
>>traditionally for reflection, and increasingly for runtime class linking 
>>under the new ABI. However, the compiler doesn't use the metadata, so of 
>>course you need to keep .class files around to compile against. Having 
>>the compiler use it is an interesting idea, however - the metadata is 
>>complete enough, so really its just down to some design/technical 
>>challenges in having the compiler read from the object files.
>>>>>Yup thats what I've thought.
>A question though: the class information is kept in a generated class
>derived from java::lang::natClass right?
>>The metadata is in the instances of java.lang.Class themselves - you can 
see the layout of this in java/lang/Class.h.
>>Currently, the compiler outputs the data in various binary structures 
>>containing pointers to Utf8 strings, etc. This format is quite "rigid" 
>>in that it doesn't allow much extensibility without breaking binary 
>>compatibility. Its also quite inefficient in terms of both space in the 
>>binary, and startup time spent in the dynamic linker resolving all the 
>>pointers. The idea (post-4.0) is to switch to a new pointer-free 
>>metadata format, in order to address all of these issues.
>>>>>Oh great. This is interesting. Have to look into the details of this.
>Do you have a pointer to the gcj implementation of these?
>>Most of the functions that deal with the metadata are currently in 
java/lang/natClass.cc and java/lang/natClassLoader.cc. In the BC-ABI 
branch, Tom has moved much of it to the new file link.cc which deals 
with class linking, runtime vtable layout, etc.
>Btw I also think that the
>otable/atable linking stuff would be great to have for D too (But I am
>not that D expert,
>
Yes, I think binary compatibility at the class/object level is very 
important for any modern OO language. The lack of this is a serious 
problem for C++, for example.
> I simply stumbled over it some time ago, and since I
>am doing some research on GCC well, I thought it would be a good
>excercise, and I'm only working on it as a hobby.
>>Since D has all that Java stuff (Class metadata, garbage collection,
>...) it would be intersting to see where GCJ and D can meet. (perhaps
>making D link against GCJ object files would be neat). And since the D
>specification deals with a lot of linkage formats and stuff like that,
>native langauge interoperability would be more easy to do here.
>>>What seems interesting to me is also the question, whether one can
>abstract the class layout from the invoking client and the linker
>Perhaps by using some inline stub code, which like the .plt stuff would
>just be invoked once with some delay. 
>I'm not sure whether D has the concept of class initialization, but Java 
has an advantage here in that its quite easy to implement a relatively 
lazy linking model (even with static compilation), without incurring too 
much runtime overhead. Since classes are guaranteed to be initialized 
before use, you can defer most of the linking work until initialization.
Regards
Bryce