RFR: 8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps

[Erik Österlund]

Hi Erik,

Thanks for the review.

/Erik

On 2019-09-04 17:26, Erik Gahlin wrote:
> Looks good.
>
> Erik
>>
>> On 31/08/2019 12:25 am, Erik Österlund wrote:
>>> Hi,
>>>
>>> Ping. This patch is a prerequisite for pushing the now reviewed
>>> 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved()
>>>
>>> And that is needed for the ZGC mac port.
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 2019-08-07 10:18, Erik Österlund wrote:
>>>> Hi,
>>>>
>>>> The JFR leak profiler has marking bit maps that assume a contiguous 
>>>> Java heap. ZGC is discontiguous, and therefore does not work with 
>>>> JFR. If one tried to use the JFR leak profiler with ZGC, it would 
>>>> allocate a bit map for the multi-terabyte "reserved region", even 
>>>> though perhaps only 64 MB is used, spread out across this address 
>>>> space. That is one of the reason the leakprofiler is turned off for 
>>>> ZGC.
>>>>
>>>> In order to enable leakprofiler support on ZGC, the tracing must 
>>>> also use the Access API instead of raw oop loads. But that is 
>>>> outside the scope of this RFE; here we deal only with the 
>>>> discontiguous address space problem.
>>>>
>>>> My solution involves implementing a segmented bit map, that makes 
>>>> no assumptions about the layout of the Java heap. Given an address, 
>>>> it looks up a bitmap fragment from a hash table, given the high 
>>>> order bits of a pointer. If there is no such fragment, it is 
>>>> populated to the table. The low order bits (shifted by 
>>>> LogMinObjAlignmentInBytes) are used to find the bit in the bit map 
>>>> for marking an object in the traversal.
>>>>
>>>> In order to not cause regressions in the speed, some optimizations 
>>>> have been made:
>>>>
>>>> 1) The table uses & instead of % to lookup buckets, ensuring the 
>>>> table is always a power of two size.
>>>> 2) The hot paths get inlined.
>>>> 3) There is a cache for the last fragment, as the probability of 
>>>> two subsequent bit accesses for two objects found during tracing in 
>>>> the heap do not cross the set up fragment granule (64 MB heap 
>>>> memory) boundary. This is something G1 exploits for the cross 
>>>> region check, and the same general idea is applied here. The code 
>>>> also asks first if a bit is marked and then marks it, as two calls. 
>>>> The cache + inlining allows the compiler to lookup the fragment 
>>>> only once for the two operations.
>>>> 4) Keep the table sparse.
>>>>
>>>> As a result, no regressions that are outside of the noise can be 
>>>> noticed with this new more GC-agnostic approach.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8229189
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8229189/webrev.00/
>>>>
>>>> Thanks,
>>>> /Erik
>