RFR: mmap connection matrix

[Roman Kennke]

OK then

Am 22. Mai 2017 13:00:58 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>On 05/22/2017 12:45 PM, Roman Kennke wrote:
>> Am 22.05.2017 um 12:19 schrieb Aleksey Shipilev:
>>> On 05/22/2017 12:11 PM, Roman Kennke wrote:
>>>> Am 22.05.2017 um 11:41 schrieb Aleksey Shipilev:
>>>>> Hi,
>>>>>
>>>>> Currently the connection matrix is allocated in C heap. We can
>make it
>>>>> consistent with marking bitmaps by mmap-ing the matrix as well:
>>>>> 
>http://cr.openjdk.java.net/~shade/shenandoah/matrix-mmap/webrev.01/
>>>>>
>>>>> Testing: hotspot_gc_shenandoah
>>>>>
>>>>> -Aleksey
>>>>>
>>>> It seems ugly that the allocation of the matrix is outside the
>>>> ConnectionMatrix class. ShenandoahHeap now needs knowledge about
>>>> internals of ConnectionMatrix.
>>> There is already a fair amount of cohesion between ShMatrix and
>ShHeap. This
>>> change makes ShMatrix the "view" over naked bitmap allocated in
>ShHeap.
>>>
>>> Consider the upside: matrix can now be allocated with proper page
>sizes and
>>> alignment.
>> 
>> Why not put that part here:
>> 
>> + ReservedSpace matrix_bitmap(_max_regions * _max_regions,
>page_size);
>> + os::commit_memory_or_exit(matrix_bitmap.base(),
>matrix_bitmap.size(), false,
>> + "couldn't allocate matrix bitmap");
>> + MemTracker::record_virtual_memory_type(matrix_bitmap.base(), mtGC);
>> 
>> 
>> inside ConnectionMatrix constructor?
>
>Tried that, looks worse: there are const fields we want to do in
>initializer
>lists, but the ReservedSpace block should precede ShenandoahMatrix
>constructor;
>we need to pass in page_size, etc. Seems cleaner to keep that in
>ShHeap.
>
>-Aleksey

-- 
Sent from my FairPhone