Re: java.lang.Character

[Eric Blake <ebb9 at email dot byu dot edu>]

Bryce McKinlay wrote:
> 
> One small concern I have is that having these tables as Strings (as
> opposed to char[]) is going to increase startup cost and memory usage
> because the runtime must copy them and do a utf8->utf16(?) conversion
> during initialization, while if they were char[] they would stay in
> shared pages and not require initialization. Why use Strings?

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?

You do have a point, however, that String.value is not available in
gcj.  There is the alternative of using the public API of
String.toCharArray(); it is probably less efficient, but will work. 
Then again, maybe the gcj front-end could inline String.toCharArray(),
the way it does things like Math.sin().

With the char[] alternative, notice that CharData must be initialized,
as the character database would no longer be stored in compile-time
constants.  I suppose it just comes down to which initialization style
is more efficient: when compiling to bytecode, the choice is between a
ton of code (dup, sipush, castore sequences) to do an array initializer,
or a single ldc that relies on behind-the-scenes native initialization,
including utf8->utf16.  But when gcj compiles to native code, it
probably does better with explicit char[] initializers.  I'll make the
change to char[] for the libjava version of Character, and ask for
approval again before I commit anything.  Then we will need to decide
whether to back port the change to Classpath, or let the two
implementations differ on this detail.

> 
> libgcj has a different java.lang.String implementation to classpath, and
> it doesn't look like this code will work without changing something (eg
> String.data -> String.value)
> 
> The old java-chardata.h etc can be deleted when this patch goes in.

Where is java-chardata.h?  I noticed that natCharacter.cc is not needed,
but could not find any other native files that are obsoleted.  Then
again, I'm relatively new to the internals of gcj, and don't know where
to look.

That just gave me a thought.  A third option for initialization is to
store the information as a jcharArray in natCharacter.cc, and doing the
initialization directly in native code.  Is this idea worth pursuing, or
is using char[] in CharData.java sufficient?

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer