Community
Participate
Working Groups
In profiling startup of one of the applications I support I saw the class initializer for org.eclipse.swt.internal.image.JPEGFileFormat accounted for >2% of instructions executed in the scenario. This seemed excessive -- upon investigation discovered code of the form: static int[] someClassTable; static { someClassTable = new int[2048]; for ( int i = 0; i < someClassTable.length; i++ ) { someClassTable[i] = some computation; } } It turns out the access to the class variable from within the class initializer is quite expensive -- changing the code to store thru a local: static { int[] local_ClassTable = new int[2048]; // someClassTable = new int[2048]; for ( int i = 0; i < someClassTable.length; i++ ) { local_ClassTable[i] = some computation; } someClassTable = local_ClassTable; } Applying this change to initializeBitCountTable(), initializeRGBYCbCrTables() initializeYCbCrRGBTables() results in an instruction count of approx 0.7 million for the JPEGFileFormat class initializer. Without the change the instruction count is in excess of 120 million. I can provide the changed code via email.
We are unlikely to change this without a benchmark. Do you have one?
I looked at the code. We are initializing a bunch of static tables that are constant. There are many tables so the result is quite a bit of memory gets allocated. This may cause a garbage collect.
Ok, it seems that accessing a static variable during class initialization must lock the class in case it is being initialized from another thread. I am amazed that this actually makes a difference but it also doesn't hurt to change the code. Carolyn, just fix it.
Fixed > 20080211