RFR(S): 8215893: Add better abstraction for pinning G1 concurrent marking bitmaps.

[Thomas Schatzl]

Hi,

On 09.10.19 23:41, sangheon.kim at oracle.com wrote:
> Hi Kishor,
> 
> On 10/4/19 4:15 PM, Kharbas, Kishor wrote:
>>
>> Hi Stefan,
>>
>> Thanks for the review. Some comments inline.
>>
>> New webrev : 
>> http://cr.openjdk.java.net/~kkharbas/8215893/webrev.00_to_01/
>>
>> http://cr.openjdk.java.net/~kkharbas/8215893/webrev.01/ 
>> <http://cr.openjdk.java.net/~kkharbas/8215893/webrev.01/>
>>
> I am reviewing the patch but have a question on top of Stefan's 
> question[1].
> Why the bimap mappers are committed? I think all troubles started from 
> 'committing but treating as special here. Couldn't just treat the bitmap 
> mappers as 'special' without commit?
> If 'not committing' is doable, couldn't simply create ReservedSpace with 
> 'special' enabled (independent to large page setting, which is same to 
> Stefan's comment)? Or add PinnedResevedSpace to force 'special enabled'.
> 
> [1]: Another thing, can you remind me why we need the bitmaps to be 
> pinned but not other structures such as the card table?
> 
> +HeterogeneousHeapRegionManager::initialize() ...
> 
> + // We commit bitmap for all regions during initialization and mark the 
> bitmap space as special.
> + // This allows regions to be un-committed while concurrent-marking 
> threads are accesing the bitmap concurrently.

   what is the situation where G1 would uncommit parts of the heap while 
concurrent marking is running? Stale entries in the mark task queues?

Regular G1 limits uncommitting of regions (and associated data 
structures) to after concurrent marking.

Note that if never releasing mark bitmaps is really necessary, then 
never releasing card/offset table is probably required as well.

Thanks,
   Thomas