RFR JDK-8059510 Compact symbol table layout inside shared archive

[Aleksey Shipilev]

Hi Jiangli,

On 12/03/2014 12:44 AM, Jiangli Zhou wrote:
> http://cr.openjdk.java.net/~jiangli/8059510/webrev.06/

Looks good.

> New in the webrev:
> 
> 1. Further compression of the compact table
> 
>   * Remove the bucket_size table. With the sequential layout of the
>     buckets, lookup process can seek to the start of the next bucket
>     without the need of the current bucket size. For the last bucket, it
>     can seek to the end of the table. The table end offset is added to
>     the archived data.
>   * Bucket with exactly one entry is marked as 'compact' bucket, whose
>     entry only contains the symbol offset. The symbol hash is eliminated
>     for 'compact' buckets. Lookup compares the symbol directly in that case.

I'll keep this for others to review.

> 2. The shared symbol table is not always looked up first. The last table
> that fetches symbol successfully is used for lookup.

This is a good stuff.

> I measured using the classloading benchmark that Aleksey pointed to me.
> This benchmark loads classes using user defined classloader. There is a
> very small degradation shown in the benchmark comparing 'before' and
> 'after' with archive dumped with the default configuration. When symbols
> from the test is added to the shared table, there is an observable
> speedup in the benchmark. The speedup is also very small.

Yes, I have remeasured on my scenario, and there seems to be no
statistically significant degradation now.

-Aleksey.