for review (M): 6652736: well known classes in system dictionary are inefficiently processed

[John Rose]

http://homepage.mac.com/rose00/work/webrev/6652736

For putback to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot
6652736: : well known classes in system dictionary are inefficiently  
processed
Summary: combine many scalar variables into a single enum-indexed  
array in SystemDictionary.

-- John

P.S.  Here's text from http://bugs.sun.com/bugdatabase/view_bug.do? 
bug_id=6652736 :

The SystemDictionary class has about 60 C static variables which hold  
well-known classes.  They should be consolidated into a single static  
block of C array-type, indexed by an enum, as in vmSymbols.  This  
will simplify maintenance and scaling and allow certain optimizations.

At JVM bootstrap, approximately 25% of all symbol lookups resolve to  
these symbols.  It is probably worthwhile making a fast path for  
these (using vmSymbols::find_sid).

The object code which operates on these classes as a group (for GC  
and initialization) will be much more compact if they are made into  
an array indexed by an enum.  Several object files are smaller by  
1-10Kb, including systemDictionary.o, vmStructs.o, javaClasses.o, and  
jvm.o, and the DLL is about 40Kb smaller.

The number of well-known classes will increase as new low-level  
features are added to support other languages.  Adding them should be  
as simple as adding new vmSymbols.

Benefits:
  - fewer symbols in the binary
  - code simplification
  - a fast path through the class lookup routine
  - easier expansion in the future

P.P.S.  Process notes:  This is the form of review request message  
we've been using internally for years.  It seems a good starting  
point for the corresponding OpenJDK communication.  The (M) means the  
proposed change is "medium" in size.  (Compare XS, S, M, L, XL,  
etc.)  Someday the webrevs will be organized on server dedicated to  
OpenJDK, instead of my mac.com account.  This change set could also  
be submitted through another hotspot gate (like runtime), but the  
compiler gate is equally relevant, and is managed by the submitter's  
immediate workgroup.  Any of these details are open to change, but if  
we try to change all of them right away, we'll never get any work  
done....