This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binary metadata


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]