Code and Design Feedback request: 7114376: tune system dictionary size

[Karen Kinnear]

Please review initial proposal for: 7114376: tune system dictionary size

http://oklahoma.us.oracle.com/~kmkinnea/webrev/sdresize/webrev/

In addition to a code review, I would appreciate feedback on the tuning flags.

The underlying goal is to optimize performance for customers loading lots of classes
by dynamically resizing the system dictionary (loaded class cache) to reduce lookup times for "find" calls.
Today the system dictionary is implemented as a hash table of buckets and all loaded classes that hash
into the bucket are linked off of that bucket. 

average_depth = # loaded classes/number of buckets.
average_lookup_length = number of links walked/number of lookups

If you load 10,000 classes with the default 1009 buckets, you have an average_depth of 10.

Longer term we will want to enhance this to allow trade-offs between customers who want
to optimize for minimum size and those who want faster performance, so please keep that in
mind - if there is a way to specify that in the interface now, without implementing the shrinking 
heuristics yet, that would be appreciated.

Proposal:

1) Dynamic resizing
If the lookup path for classes is "too long", then the system dictionary is automatically resized.

2) Tunable heuristics
  1. starting size
      -XX:SystemDictionarySizeIndex (0-7)
      This sets the initial system dictionary size. The sizes you get are:
       1009 (default = current value), 2017, 4049, 50501, 10103, 20201, 40423, 99991

   2. "too long"
       The default value for too long was taken from the existing verification assertion which used to
       print a warning, i.e. if (average_lookup_length) > 2 * (average_depth).
       Actually, unless you have just unloaded > 20% of the current classes.

   3. frequency of checking
       This prototype checks for resizing when we check for class_unloading, which I believe is
       called during full GCs.
       I added the flag SystemDictionaryAverageDepth=# to allow running benchmarks to see
       if there is too much overhead if we check at every safepoint. I am gathering those results in parallel
       with this feedback request. My current goal is to remove this flag and check at every safepoint
       if this doesnt' cost too much.

   4. Total allowable sizes
      The max allowable size with the prototype is 99991. Do we need larger numbers today?
       If you load 1 million classes you would have an average_depth of ~10.

    5. I changed -XX:+PrintSystemDictionaryAtExit to a diagnostic flag so customers could find
        out the number of classes they are loading, and added additional information to that dump.

3) Tuning alternatives
  1. Starting Size
      * The algorithm for hashing optimizes even distribution for a table with a prime number of buckets.
      Would customers prefer to enter their own explicit table size, which may or may not be a prime number,
      rather than selecting a size index?

       * OR Would it be easier for backward compatibility as we allow both smaller and larger sizes if the customer
       were to specify:
       XS, S, M, L, XL for instance - and this would allow us to add XXS, XXL, etc. to the command-line later
       and to fit additional incremental sizes for dynamic tuning in between without changing the required command-line?
        - I prefer this approach, but would like feedback.

   2. Resize or Not? Or Allow/disallow Growing? Allow/disallow Shrinking? Optimize for small size? Optimize for speed?
       Do we need different and/or better controls? Suggestions please?
       For the optimize for speed/optimize for small size - I would suggest that there might be more general flags that
       specify those in the future, and that the system dictionary resizing take those more general flags into account, rather than
       having specific flags for optimizing the system dictionary size/look up speed. 

   3. SystemDictionaryAverageDepth=#
       Should I remove this - is this adding a level of unnecessary complexity?
       Or should I leave this and use it to have the dynamic resize use this to determine the new size
       rather than simply incrementing each time? My preference is to remove this at this time to simplify
       the implementation until we have more experience in the field.

thanks,
Karen