This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: shriveling libgcj
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: shriveling libgcj
- From: Per Bothner <per at bothner dot com>
- Date: Sat, 10 Nov 2001 23:59:41 -0800
- CC: Tom Tromey <tromey at redhat dot com>, Adam Megacz <gcj at lists dot megacz dot com>, java at gcc dot gnu dot org
- References: <Pine.LNX.4.10.10111102346510.23080-100000@mars.deadcafe.org>
Jeff Sturm wrote:
>Shrinking class metadata would help reduce both the initialized data and
>relocation sections, which appear to be a larger portion of the
>executable. Also this would work fine together with -fvtable-gc.
>
I have an idea to consider: Replace the initial meta-data by a compact
and pointer-free
encoding. Then the first time we need to access relection for this class we
decode this representation into the java.lang.reflect
representationation. I.e.
instead of an array of _Jv_Method encode the information in a string
containing
no pointers stored in the text segment (or constant data segment). Thus the
encoding needs no relocation, which speeds spart-up on systems using
shared libraries
as well as being compact.
Then instead of jmethodID being an alias for _Jv_Method* it would become an
alias for java::lang::reflect::Method*.
--Per