RFR JDK-8059092: Store Interned Strings in CDS Archives

[Bengt Rutisson]

Hi Tom,

Thanks for providing the great summary that eased the review process. 
This change looks good to me.

Some minor comments:

g1Allocator.cpp

  214   assert(_bottom >= _allocation_region->bottom(), "inconsistent 
allocation state");
  215   assert(_max <= _allocation_region->end(), "inconsistent 
allocation state");
  216   assert(_bottom <= old_top && old_top <= _max, "inconsistent 
allocation state");

Maybe add err_msg() to see what the values actually were?


g1CollectedHeap.cpp

  965 bool
  966 G1CollectedHeap::check_archive_addresses()

We usually don’t have a linefeed after the return type. So, this should be:

  965 bool G1CollectedHeap::check_archive_addresses()

Same for G1CollectedHeap::alloc_archive_regions() and 
G1CollectedHeap::fill_archive_regions()


g1MarkSweep.cpp

  306 void G1MarkSweep::enable_archive_object_check() {
  307   if (!_archive_check_enabled) {

Shouldn’t this be called exactly once, either from 
G1RecordingAllocator::create_allocator() or 
G1CollectedHeap::alloc_archive_regions()? In that case maybe the “if” 
should be changed to an assert or guarantee that !_archive_check_enabled 
holds.

Thanks,
Bengt


On 29/05/15 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
> 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 used	Program   Saving
>   28.0 MiB + 110.5 KiB =  28.1 MiB	java
>   31.5 MiB +  12.6 MiB =  44.2 MiB	java (2)
>   47.2 MiB +  12.7 MiB =  59.9 MiB	java (3)
>   63.2 MiB +  12.8 MiB =  76.1 MiB	java (4)
>   78.0 MiB +  12.9 MiB =  90.8 MiB	java (5)
>
> With Shared String
>   27.6 MiB + 111.5 KiB =  27.7 MiB	java           0.4M
>   23.7 MiB +  16.3 MiB =  40.0 MiB	java (2)      4.2M
>   35.3 MiB +  16.4 MiB =  51.7 MiB	java (3)      8.2M
>   48.3 MiB +  16.5 MiB =  64.8 MiB	java (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
>