RFR JDK-8059092: Store Interned Strings in CDS Archives

[Per Liden]

On 2015-05-29 21:39, Jiangli Zhou wrote:
> Greetings,
>
> Please review the changes for supporting interned String objects and the
> underling character arrays in the CDS shared archive. The webrevs listed
> below only include the runtime changes. The webrev for GC specific
> changes will be sent out by Tom Benson shortly.
>
> *JEP*
> https://bugs.openjdk.java.net/browse/JDK-8059092
>
> *Webrev*
> hotspot :
> http://cr.openjdk.java.net/~jiangli/8059092/webrev_hotspot.01/index.html

The parts interacting with string deduplication look good.

cheers,
/Per

> whitebox:
> http://cr.openjdk.java.net/~jiangli/8059092/webrev_wb.01/index.html
>
> *Summary*
> The shared strings support is added on top of the basic CDS function
> that enables the archiving of the interned String objects and String’s
> underlying ‘value' array objects from the java heap. During CDS dump
> time, all Strings referenced from the string table is copied into a
> special region in java heap, which is at the top of the dump time java
> heap. The special region is referred as the string space. While copying
> the String related objets, a compact table is created for storing the
> references to the copied Strings. Both the compact table and the string
> space are written into the CDS archive with the rest of the class
> metadata during dumping. The compact table for shared strings uses the
> same format as the shared symbol table in CDS archive and shares
> implementations.
>
> At runtime, the string space is mapped at the same offset from the
> narrow oop encoding base as dump time within the java heap. That allows
> the shared strings to be ‘partially’ relocatable, which means the
> runtime java heap could be at different address location and have
> different size from the dump time java heap as long as the same narrow
> oop encoding can be used. If the narrow oop encoding changes due to the
> large difference between the dump-time and runtime heap sizes, the
> shared string space from the CDS archive is ignored and not mapped to
> the VM address space.
>
> The mapped string space is an ‘archive’ region in the java heap. All
> shared objects residing within the region are not collected or forwarded
> by GC. GC activities never write to the memory pages that are mapped as
> the shared string space. The identity hash of shared objects in the
> string space are pre-computed during CDS archive dump time. The only
> possible ‘write’ to the shared string space at runtime is from
> synchronization on the shared objects. That allows majority or all
> mapped string memory to be sharable between different VM processes.
>
> Only 64-bit process is supported for shared strings due to the
> dependency on the narrow oop support. Windows is not supported currently.
>
> *Performance Results*
> *Memory*
> Tested using about 3M of string data for memory measurement. Memory
> results were measured using linux ps_mem tool.
> *No Shared String*
>   Private  +   Shared  =  RAM usedProgram   Saving
>   28.0 MiB + 110.5 KiB =  28.1 MiBjava
>   31.5 MiB +  12.6 MiB =  44.2 MiBjava (2)
>   47.2 MiB +  12.7 MiB =  59.9 MiBjava (3)
>   63.2 MiB +  12.8 MiB =  76.1 MiBjava (4)
>   78.0 MiB +  12.9 MiB =  90.8 MiBjava (5)
>
> *With Shared String*
>   27.6 MiB + 111.5 KiB =  27.7 MiBjava *0.4M*
>   23.7 MiB +  16.3 MiB =  40.0 MiBjava (2) *4.2M*
>   35.3 MiB +  16.4 MiB =  51.7 MiBjava (3) *8.2M*
>   48.3 MiB +  16.5 MiB =  64.8 MiBjava (4) * 11.3M*
> 60.6 MiB+ 16.5 MiB= 77.2MiB java(5) *13.6M*
> *
> *
> *Runtime Performance*
> Tested on isolated linux-x64 machine.
> *SpecJVM98*
> ==============================================================================
> logs.specjvm.before2:
>    Benchmark           Samples        Mean     Stdev             Geomean
> Weight
>    specjvm98                10      603.39     23.25
> ==============================================================================
> logs.specjvm.after2:
>    Benchmark           Samples        Mean     Stdev   %Diff     P
> Significant
>    specjvm98                10      604.89     10.85    0.25 0.856
>        *
> ==============================================================================
>
> No performance degradation shown in specjvm.
>
> *Testing*
> Tested with:
>
>   * Developed unit tests
>   * JPRT
>   * Full QA test cycle: vm.gc, vm.runtime,nsk.sysdict, vm.metaspace,
>     vm.quick, JCK: vm, lang, api, KS-24hrs, runThese
>
> Thanks,
> Jiangli
>