binary metadata

Mon Sep 27 18:55:00 GMT 2004

Jakob Praher wrote:
>I think I've heard that you are going to replace the generated class
>file (currently as a generated c++ class) by binary metadata placed into
>the object file. ( perhaps a .meta elf section ... )
>>Hi Jakob,
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.
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.
Using an ELF section for the metadata is probably a good way to go, 
however for GCJ we'd want a fallback option for non-ELF platforms that 
don't support named sections. What I had in mind was to extend the .jcr 
(Java class registration) section that we already use, so that instead 
of containing a list of pointers to static java.lang.Class objects, it 
contains a) Utf8-encoded class name, and b) PC-relative byte-offset to 
the rest of the classes metadata. This way class registration becomes 
very cheap, since the full metadata only needs to be loaded when the 
class in question is actually resolved/linked, and only a small amount 
of memory is touched when loading a large shared library like libgcj.so.
>Do you have already plans/specifications for the meta data?
>Will the meta data spec be tied to java type system or is it generic
>enough for any kind of meta data?
>>
There arn't any detailed specifications for the pointer-free metadata at 
this point, beyond a few ideas that have been posted to the list from 
time to time. Making the format extensible so that other languages can 
use it too is certainly a good idea. It would permit tool 
interoperability and be useful for multi-language runtimes. I suspect it 
may be a lot of work to develop a specification which is simple, 
efficient and also general enough to encompass a fairly diverse set of 
languages like Java, C#, and D.
Regards
Bryce