The performance of java.lang.Class.isAssignable api in SUN's jdk1.5.0_06 build 05 lags behind the peformance of the same in JRockit's jdk1.5.0_06. 

The JRockit api takes 50% (or half) of the time that SUN's jdk1.5.0_06 takes, after the "warm-up". This was measured using a simple micro-benchmark that repeatedly called isAssignableFrom. 

Object.isAssignableFrom(Vector)

The measurement was done on Solaris 10 on SPARC.

Right now, I am filing this bug so that it's on the radar. I will be digging deeper for more details.
Posted Date : 2006-08-19 00:30:20.0

N/A

I have the bug reproduced and it is not pretty, we need to consider 
intrinsifying the IsAssignableFrom method, needs further evaluation to backport fix from 7.0.Commiting to mustang update, as this fix is not appropriate for 6 RC.
Posted Date : 2006-08-30 16:53:31.0

This is a point fix which can be backported from Dolphin.
I am targeting it for 5.0u12 (on the sub-CR) and 6u2.
See suggested fix for a webrev.
It is co-packaged with another point fix in the same code, for 6297094.
Posted Date : 2006-12-09 23:25:00.0

It's a badly designed benchmark, so the numbers must not be taken quantitatively; they provide an order-of-magnitude indication of code quality only.

As is the case with many microbenchmarks, the warm-up phase OSRs, and the timing phase runs non-OSR code.  In this case, the timing numbers are disturbed by the non-OSR compilation that occurs.

A quick fix to this (though probably not a stable one) is as follows:

--- Main.java~	2006-08-14 16:06:57.000000000 -0700
+++ Main.java	2007-01-16 16:50:44.033302000 -0800
@@ -103,9 +103,11 @@
     private void run(){
         
         runIsAssignableFrom("isAssignable warm-up time");
+        runIsAssignableFrom("isAssignable warm-up time #2");
         runIsAssignableFrom("isAssignable run time");
         
         runSetField("setField warm-up time");
+        runSetField("setField warm-up time #2");
         runSetField("setField run time");
     }
     

When creating a benchmark, always try it out with -XX:+PrintCompilation and recode until there are no compilations occurring during the timing phase.  Also run -Xbatch, of course.  The #2 warm-up calls run into the -Xbatch execution barrier and wait for the non-OSR compilation of each test to finish before starting the timing run.

Also, result of the call to isAssignableFrom is not tested or otherwise used.  That potentially allows more optimization (or cheating!) than the benchmark attempts to test.  In this case, the open-coded call to isAssignableFrom can disappear completely.  If this happens, the loop containing it also disappears, except for a single iteration to perform null checks on the operands.  So any time reported has nothing to do with the speed of isAssignableFrom.
Posted Date : 2007-01-17 01:20:16.0

Actually, independent of whether the specific micro-benchmark is valid or not, isAssignableFrom() is hideously slow on JDK 1.5, and probably on JDK 1.6 as well. This means that field access via reflection becomes a bottleneck for many data binding libs/frameworks. For 1.5, calling get/set methods via reflection seems to be 5x - 10x faster than field access/mutation via reflection.

However, with 1.6, this is shadowed (wrt. reflection-based method calls or field access) by insanely slow security checks, which also make reflection-based method calls seriously slow (more than two orders of magnitude slower than regular in-linable get/set method calls). Both will now be one order of magnitude slower than (relatively less slow) 1.5 method calls via reflection.