RFR JDK-8059510 Compact symbol table layout inside shared archive

[Jiangli Zhou]

Hi Christian,

The test was included in a separate webrev for JDK-8021834 
<https://bugs.openjdk.java.net/browse/JDK-8021834>, which is related to 
this enhancement.

Thanks,
Jiangli

On 10/02/2014 02:54 PM, Christian Tornqvist wrote:
> Hi Jiangli,
>
> I don't see any tests included in the webrev for this enhancement?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Jiangli Zhou
> Sent: Thursday, October 2, 2014 5:33 PM
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: RFR JDK-8059510 Compact symbol table layout inside shared archive
>
> 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
>
>
>