Re: java.lang.Character

[Per Bothner <per at bothner dot com>]

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, except it's a fairly hefty piece of optimization.  The compiler
has to realize that it can optimize the tables, and then get rid of the
other-wise unused Strings.  This is non-trivial.

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.

> 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.

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'll make the
> change to char[] for the libjava version of Character, and ask for
> approval again before I commit anything.

No, I will not approva that either.  The only solution I will accept
is one that is no worse than the current solution.  That probably
means using constant C-style tables.

I apologize, I should have caught this and spoken up earlier.  I got
the impression we were talking about updating replacing the scripts to
generate the tables.  Perhaps it would make sense to extend/modify
the scripts so they generate C-style native arrays like we currently do?
Could I ask you to take a look at that?

> Where is java-chardata.h?

In libjava/include.  It is automatically generated by chartables.pl.

   I noticed that natCharacter.cc is not needed,

We will keep natCharacter.cc.

> 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 is close, but it has the basic problem that as soon as you have a
valid Java obejct (char[] or String) you need an Object header, which
includes a vtable pointer.  This pointer needs relocation, so it cannot
be in a shared memory segment.  That is why I'm insisting of C-style
native arrays - they don't have an Obejct header.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/