RFR: mmap connection matrix

[Aleksey Shipilev]

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