java.lang.Character

[Bryce McKinlay]

Per Bothner wrote:

> Eric Blake wrote:
>
>> Notice that the Strings are compile-time constants, and that interface
>> gnu.java.lang.CharData should never need initialization, as the
>> constants are inlined into Character.  What's stopping gcj from doing
>> the utf8->utf16 conversion at compile-time, and storing String data in
>> char[] format instead of utf8? 
>

Nothing. It is a trade-off between smaller binaries (saving 1 byte per 
character in the general case) vs quicker initialization and reduced 
heap usage. But, after doing some quick profiling, a typical command 
line app initializes < 50K worth of string constants vs 300K+ (after 
merging) of Utf8Consts in libgcj (I'm not sure how many of those are 
actually strings, though - most are probibly reflection metadata).

> The current code can place the tables in *read-only, non-relocatable*
> shared text segments.  You cannot do that with Strings *or* with char[]
> assuming we're talking about Java arrays, not C arrays. 


Per is right. Even a char[] can not be a true constant, because it needs 
a vtable pointer which requires a relocation when in or linking against 
a shared library. This problem potentially goes away with prelinking 
(vtable pointer can be constant), but we can't really assume that until 
if/when prelinking is widely used.

> It doesn't matter:  The current mechanism using constant, C-style
> native arrays wins over both.  The only benefit to the classpath
> approach is that it doesn't need native code; that is not an acceptable
> reason for replacing something more efficient, which already works. 


I agree, but if you look at the classpath code you'll see that it is 
also a much more efficient implementation. So, we want to use the 
tables/algorithms from Eric/classpaths implementation, but do it in C.

regards

Bryce.