This is the mail archive of the
mailing list for the GCC project.
Re: Java: [BC] Implement type assertion table
Tom Tromey wrote:
I tried out the type assertion patch today.Hmm. I suspect most of these assertions would not actually occur in
practice, though, unless perhaps we are compiling illegal bytecode. ie:
assignment of an array to a non-Object type would be an error at compile
time, and, AFAIK, an array type can't possibly change at runtime to a
Bryce> +vfy_is_assignable_from (vfy_jclass target, vfy_jclass source)
[ ... ]
Bryce> + /* Any class is always assignable to itself, or java.lang.Object. */
Bryce> + if (source == target || target == object_type_node)
Bryce> + return true;
We can do further optimizations in the case of arrays. An array is
always assignable to Serializable or Cloneable, and never assignable
to anything other than Object or another array type. Likewise,
non-arrays are never assignable to an array type.
So, if we have, say, a Foo being assigned to a Bar, we strip off the
array type and just emit Foo->Bar?
On the subject of arrays, I saw a crash running Eclipse because the
assertion table held some array types, but link.cc isn't ensuring that
all the necessary supers are installed. (Actually linking seems to be
a problem in general.) I have a runtime patch for this, but it seems
to me that if we stripped off the arrays in the compiler we could
probably improve the chances of sharing entries (and utf8consts) and
potentially reduce the size of the table.
On a related note, I was wondering about the use of class signatures
rather than regular class names in the assertion table. Using class
names instead would definitely increase Utf8Const sharing. Im not sure
why the signature is used but thought it prudent to leave it that way
for now. Andrew, does this ring any bells from when you wrote the