RFR 8042668: GC Support for shared heap ranges in CDS (RE: JDK-8059092)
Per Liden
per.liden at oracle.com
Mon Jun 1 14:35:00 UTC 2015
Hi Tom,
On 2015-05-29 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/
Maybe it's just me, but the concept of "recording" feels a bit strange
in this context. May I suggest that we remove the "record" and
"recording" part of the names and instead just call it an "archive" that
we can allocate in? Something like:
class G1ArchiveAllocator ... {
HeapWord* mem_allocate(...);
void finalize(...);
...
};
class G1CollectedHeap ... {
void begin_archive_mem_allocate();
bool is_archive_mem_allocation_too_large(...);
HeapWord* archive_mem_allocate(...);
void end_archive_mem_allocate(...);
...
};
g1CollectedHeap.cpp
-------------------
* In G1CollectedHeap::end_record_alloc_range(), shouldn't we delete the
allocator as the last step?
* I guess this change could be skipped, as it makes the comment slightly
malformed.
- // We ignore humongous regions, we left the humongous set unchanged
+ // We ignore humongous regions.
+ // We left the humongous set unchanged,
g1Allocator.hpp
---------------
+ class G1RecordingAllocator : public CHeapObj<mtGC> {
+ friend class VMStructs;
You could skip this friend declaration, since it's not accessed by
VMStructs. Only needed if the class is exposed in the SA.
cheers,
/Per
>
> 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
>>
More information about the hotspot-gc-dev
mailing list