Re: thoughts on new reflection data

[Bryce McKinlay <mckinlay at redhat dot com>]

David Daney wrote:
> This sounds reasonable, but I have a couple of questions and/or 
> suggestions:
>
> Would it be possible or useful to move the name and signature members 
> of _Jv_Field and _Jv_Method into these attributes?

Yes, I think it actually makes sense to have all the class metadata in a 
similar format. Classes should be described in more-or-less the same 
format that Java bytecode uses. This would replace the current "static 
jclass" approach, for the -findirect-classes case.

The only differences would be that there'd be an additional table 
containing the method pointers, and the format of the constant pool 
which would probably remain in GCJ's _Jv_Utf8Const format. These tables 
could actually consist of byte-offsets rather than real pointers, so 
that libgcj can lazily resolve them when classes are loaded rather than 
forcing the runtime linker to resolve them all in advance. (This same 
technique is used by Dwarf2).

The benefits of this are reduced memory usage, and better start-up 
performance: far less .so data needs to be copied on startup, and the 
linker needs to resolve far less symbols. It also means that our 
metadata is more extensible since new attributes can be trivially added 
in the future without breaking the ABI.
Any GCJ-specific attributes could be added to the metadata using the 
standard attribute mechanism.

Pointer free metadata has actually been a goal for a long time - Per 
proposed the idea years ago.

Bryce