[Finn Bock]

You should perhaps also be aware that the values

in a static array gets


assigned to the array one element at a time. So

static int[] a = {

101,102,103,104,105,106,107,108 };


becomes in bytecodes:

Method static {}
  0 bipush 8
  2 newarray int
  4 dup
  5 iconst_0

[Glen Mazza]


Hmmm...Are you saying that declaring a static array
isn't much (any?) faster than manually creating one?

I would guess that it is a bit faster than the typical bytecode for manually created arrays since the above uses 'dup' instead of 'getstatic' or 'aload' to push the array on the stack.


I didn't realize that there is code being run for
static arrays--I would have thought the compiled
bytecode just includes the array internally, and not
the code to create it.  (i.e., if you opened the
bytecode you would see an array 101 102 103 104...
sitting someplace.)

Arrays can't be stored in the constant pool so there is no place to put the data except as bytecode.


http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html#20080

It should perhaps be noted that constant instances of String is not really stored in the constant pool either. The pool just stores the utf-8 representation of the string constant, and each literal string is initialized as a new pool String object based on that (as UTF-16ish).

Isn't that how C works, at least?

I think so, but C has hardware support for code and data segments so C can make better use of it.


Sigh...I guess I *didn't* know bytecode by heart after
all!  ;-)

I didn't bring it up to discourage the use of static initialized arrays.
If it makes sense to put something in a static array we should do so without concern of compiletime vs. runtime. After all, the initialization is only performed once per classloader.


regards,
finn



Reply via email to