Re: binary metadata

[Jakob Praher <jpraher at yahoo dot de>]

hi Bryce and Tom,

thanks for your replies.

sorry for my delay, but I had to finish a university project (pascal to
16 bit intel compiler). :-( So at least now I know that 16bit and 32bit
Intel addresssing modes are pretty different and I appreciate having a
compiler with a good backend.

Am Mon, den 27.09.2004 schrieb Bryce McKinlay um 20:55:
> 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.
Yup thats what I've thought.
A question though: the class information is kept in a generated class
derived from java::lang::natClass right?

> 
> 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?

> 
> 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.
Yeah that's probably right. But on the other hand I would be very
interested in the way you do that. 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, 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.

Sure the problem with D is that it is not network-enabled by default.
This is that big advantage of Java, the .class files are simply great
when the network is involved.

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 think for many classed the 2
WORD offset of the class header is too much, (speking of D) and could be
optimized. But if you have a statically compiled language, that can't be
done that easily, since linking at the core is based on offsets.

anyways thanks for the info
-- Jakob
> 
> Regards
> 
> Bryce
>