type check overhead (performance...)

Thu Sep 2 11:59:00 GMT 1999

>>>>> "Norman" == Norman Hendrich <hendrich@tech.informatik.uni-hamburg.de> writes:

Norman> please excuse if the 'performance' discussion turns up
Norman> again. With my new libpthreads, I'm quite happy with
Norman> gcj/libgcj performance (but now I would like to gcj-compile
Norman> Java 1.1. internal classes and anoymous arrays...)
You can't do that yet. For now, you can compile to bytecode using
somebody else's javac, and then compile the bytecodes. Even that
won't work in some situations (e.g., if you are planning to use (CNI)
native methods on an inner class).
Norman> Perhaps you could just optimize the store-into-Object and
Norman> store-into-Object[] cases?
You can't optimize the store-into-Object[] case because a Double[] is
an Object[]. That is the problem: if you know that the array is
actually an Object[] and not some sublcass, then you can optimize.
However, in the code posted so long ago, this was not the case.
You can short-circuit this test when compiling "o[1] = o[2]" because
you know o[2] has already passed the assignable-from test, regardless
of the actual type of the array. We exploit this same optimization in
our implementation of System.arraycopy.
Tom