This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
> The example I was illustrating was a `private static final byte' array. This is not necessarily read-only. You basically have to verify that no method modifies any element, and that the array is not passed to any method (which might modify it). This is not difficult, of course. And a side benefit is that you don't have to actually create/manage a Java object - because all references are known, you can treat it as a C array (without the Java array header). If you cannot do this, or the array is non-private, or the array is non-static, you have to allocate it dynamically, but it still wins to initialize the array from a static read-only buffer, using memcpy (as you mention). > Currently, if you give gcj that java/lang/Character.class > file, it runs out of virtual memory trying to optimize all the table > initialization. Well, since we can't use Sun's classes.zip class for legal reasons, and don't want to for technical reasons, I don't think it really matter - for this specific class. Still, we do want to handle large arrays - however, handling Java source well is the first priority. We'll get to it, but i don't know when. (These arrays used to be handled even worse. However, I put in some hooks so that at least we don't emit useless code for bounds checking in these cases. That makes running out of virtual memory less likely, but it is still handled inefficienty by gcc.) --Per Bothner Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner