RFR JDK-8059510 Compact symbol table layout inside shared archive

[Jiangli Zhou]

Hi Aleksey,

Thanks a lot for the review!

Jiangli

On 12/03/2014 02:42 AM, Aleksey Shipilev wrote:
> 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.
>
>