RFR 8042668: GC Support for shared heap ranges in CDS (RE: JDK-8059092)

Fri May 29 21:30:15 UTC 2015

Hi,
Please review these changes for JDK-8042668, which constitute the GC 
support for JDK-8059092 for storing interned strings in CDS archives 
(JEP 250).  The RFR for JDK-8059092 was recently posted by Jiangli Zhou, 
and it would be best if overall comments could go to that thread, with 
GC-specific comments here.

JBS:   https://bugs.openjdk.java.net/browse/JDK-8042668
Webrev:   http://cr.openjdk.java.net/~brutisso/8042668/webrev.00/

These changes add a new "archive" region type to G1.  The description 
field in JDK-8042668 contains an "Implementation Notes" section which 
describes components of the design, and should be useful for a code 
review.   The overview:

    "Archive" regions are G1 regions that are not modifiable by GC,
    being neither scavenged nor compacted, or even marked in the object
    header. They can contain no pointers to non-archive heap regions,
    and object headers point to shared CDS metaspace (though this last
    point is not enforced by G1). Thus, they allow the underlying
    hardware pages to be shared among multiple JVM instances.

    In short, a dump-time run (using -Xshare:dump) will allocate space
    in the Java heap for the strings which are to be shared, copy the
    string objects and arrays to that space, and then archive the entire
    address range in the CDS archive. At restore-time (using
    -Xshare:on), that same heap range will be allocated at JVM init
    time, and the archived data will be mmap'ed into it. GC must treat
    the range as 'pinned,' never moving or writing to any objects within
    it, so that cross-JVM sharing will work.

Testing:  All testing for JDK-8059092 included this code.   Manual 
testing with prototype calls to the new GC support was performed before 
integration, along with JPRT and benchmark runs.

Performance:  The GC changes had no significant impact on SpecJBB, JVM, 
or Dacapo benchmarks, run on x64 Linux.  However, a small (~1%) increase 
in Full GC times was seen in tests when the shared string support was 
not in use, when runs are configured to encounter them.   When shared 
strings ARE in use, the impact could be as high as 5% for a likely 
worst-case.   Please see the JBS entry for a discussion.

Thanks,
Tom

> *From: *Jiangli Zhou <jiangli.zhou at oracle.com 
> <mailto:jiangli.zhou at oracle.com>>
> *Subject: **RFR JDK-8059092: Store Interned Strings in CDS Archives*
> *Date: *May 29, 2015 at 12:39:27 PM PDT
> *To: *hotspot-runtime-dev <hotspot-runtime-dev at openjdk.java.net 
> <mailto:hotspot-runtime-dev at openjdk.java.net>>
> *Cc: *hotspot-gc-dev at openjdk.java.net 
> <mailto:hotspot-gc-dev at openjdk.java.net>
>
> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150529/68cb05e0/attachment.htm>