RFR JDK-8059510 Compact symbol table layout inside shared archive

[Jiangli Zhou]

I had the same thought as John about the symbol entry for LP64 & !LP64 
briefly, when I took over the code. But didn't pursue further. I agree 
the differentiation between LP64 & !LP64 here is not necessary. I'll 
change it.

John, thanks for the review and comments.

Thanks,
Jiangli

On 10/02/2014 10:12 PM, Ioi Lam wrote:
> Hi John,
>
> I agree that the extra addition instruction in 32-bit would be noise. 
> I think it's OK to remove the #ifdef and always use the offset.
>
> If there were more savings in 32-bit (like if it were possible to save 
> an extra 2 bytes), then I would put up a fight, but I will concede 
> this one :-)
>
> Thanks
> - Ioi
>
> On 10/2/14, 6:57 PM, John Rose wrote:
>> I like the new compact position-independent format, but I am 
>> uncomfortable with
>> adding #ifdefs unless there is a good reason to do so.  What's the 
>> reason here?
>>
>> Maybe this is really a question for Ioi, but why use two data 
>> structures when one will do the job?
>>
>> That is, if you have to implement and support the 
>> position-independent format for LP64,
>> why not use it also for !LP64?  The extra "addl" instructions and 
>> table base pointer are noise.
>>
>> And it's not just one localized #ifdef; there are several in the 
>> proposed changeset.
>> If we do relocatable images in the future, the divergent relocation 
>> rules will cause even more.
>>
>> Overall, we should be supporting both 32- and 64-bit systems in 
>> common code,
>> and more so over time, not splitting new code with #ifdefs.
>>
>> — John
>>
>> P.S. One might think, "what's another #ifdef when there are so many?".
>> It's a judgement call, of course.  But note these two grep counts:
>> $ cat $(hg loc -I src/share/vm) | grep -c '#.*LP64'
>> 236
>> $ cat ~/Downloads/hotspot-7.patch | grep -c '#.*LP64'
>> 9
>> The proposed change adds, all by itself, 4% to our #ifdef load for LP64.
>>
>> On Oct 2, 2014, at 2:33 PM, Jiangli Zhou <jiangli.zhou at oracle.com> 
>> wrote:
>>
>>> Please review the webrev for JDK-8059510 
>>> <https://bugs.openjdk.java.net/browse/JDK-8059510> for JDK9: 
>>> http://cr.openjdk.java.net/~jiangli/8059510/webrev.00/.
>>>
>>> The shared classes in the CDS archive and runtime loaded classes 
>>> used the same symbol table, which was a hashtable with 24-byte 
>>> entries on 64-bit machine or 12-byte entries on 32-bit machine. It 
>>> also used a pointer for bucket slot. In the webrev, we separate the 
>>> symbol table for shared classes and runtime classes into two. While 
>>> the runtime symbole table remain unchanged, the shared classes use a 
>>> much compact table, which uses 8-byte per entry on both 32-bit and 
>>> 64-bit machines. Each entry contains the symbol hash (4-byte). On 
>>> 32-bit machine, it contains the pointer (4-byte) to the symbol. On 
>>> 64-bit machine, it uses 4-byte offset from the base of the table.
>>>
>>> // juint hash;
>>> //#ifdef _LP64
>>> // juint offset; /* Symbol *sym = (Symbol*)(SharedBaseAddress + 
>>> offset) */
>>> //#else
>>> // Symbol* sym;
>>> //#endif
>>>
>>>
>>> The shared symbol lookup is quick. The targeting bucket is 
>>> calculated using the hash (bucket index = hash % _bucket_count). The 
>>> bucket sizes are pre-calculated and also stored in the archive along 
>>> with the symbol table. So we don't need to calculate the bucket 
>>> sizes at runtime.
>>>
>>> The separate shared symbol table in the archive is now read-only 
>>> during runtime. No entry is added/removed from the shared symbol 
>>> table. Rehashing of the runtime symbol table does not affect the 
>>> shared symbol table in the archive either. This helps memory sharing 
>>> by avoid writes to the shared memory.
>>>
>>> As part of the change, two dumping utilities were added to jcmd for 
>>> dumping symbol table and string table.
>>>
>>> The majority of the code in the webrev were contributed by Ioi Lam.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>>
>