RFR JDK-8059092: Store Interned Strings in CDS Archives
Bengt Rutisson
bengt.rutisson at oracle.com
Mon Jun 1 08:34:55 UTC 2015
Sorry. Sent this reply in the wrong email thread. Will re-post in the
correct one.
Bengt
On 01/06/15 10:05, Bengt Rutisson wrote:
>
> 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
>>
>
More information about the hotspot-gc-dev
mailing list