Initialization of static data in Java

Thu Nov 19 12:51:00 GMT 1998

On 1998年11月19日, Per Bothner wrote:
>We definitely intend to have gcj generate generate good code for
>array initializer in Java source. There are some subtle points
>to keep in mind, theoug, such as when the atable can actually
>be static. Note it can only be static it it is final - but
>final does not imply read-only! There are also garbage
>collection implications for arrays containing references.

The example I was illustrating was a `private static final byte' array.
Similar restrictions exist for C++. For example if you define
a table or array inside of a method without saying `static', or if
you define a table inside a class without declaring it static, then the
compiler emits a ton of code to initialize the table.
Seems like even without the `static', the compiler could still initialize
the table with a static table, and memcpy the table into the per-instance
table at construction time? And without the `final', the compiler could
just maintain a reference within the object that gets overridden by
subclasses.
>While we will generate good code when given array initializer in
>Java source (though not yet), I cannot promise the same when
>compiling Java bytecodes. That requires some extra analysis.
>The analysis is probably not that difficult, but it is lower
>priority, and so will probably be written later.

I recognize the difficulty of munching all the Java VM byte codes into
a static initializer. Currently, if you give gcj that java/lang/Character.class
file, it runs out of virtual memory trying to optimize all the table
initialization. Too bad the Java VM doesn't have opcodes for
accessing static tables so that there doesn't have to be so much post-mortem
analysis to do the job right! Oh well... Nobody's going to change the Java
VM specification.
--
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790