This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Java Patch: Merge UTF-8 contants at link time
- To: green at cygnus dot com
- Subject: Re: Java Patch: Merge UTF-8 contants at link time
- From: Per Bothner <per at bothner dot com>
- Date: 13 Sep 2001 12:50:59 -0700
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- References: <200109131915.MAA16157@fencer.cygnus.com>
Anthony Green <green@redhat.com> writes:
> This patch enables the merging of gcj's UTF-8 constants at link time
> when combined with a recent gas/ld and this patch:
> http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00500.html
The next step might be to phase out Utf8Const objects and replace them
by static String objects. The latter take more space in the
executable, but they save run-time space and startup cost, since you
don't need to create a String from the Utf8Const.
One complication is the pointer from the String to String.class. It
might make sense to leave that zero and backpatch it on demand, to
reduce startup cost; on the other hand if the linker does the patching
it can place the String in read-only memory. (I don't know if it does.)
I'd start with String literals, and then re-consider the various names
in the Class, _Jv_Field, and _Jv_Method structures. Here there is a
tradeoff: a String takes more room than a Utf8Const; however the
reflection API uses Strings, and so would be sped up.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/