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

Bengt Rutisson bengt.rutisson at oracle.com
Mon Jun 1 08:35:55 UTC 2015


Hi Tom,

(Correct email thread this time, I hope.)

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 23:30, Tom Benson wrote:
> 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/20150601/1f666a54/attachment.htm>


More information about the hotspot-gc-dev mailing list