RFR: 8062063: Usage of UseHugeTLBFS, UseLargePagesInMetaspace and huge SurvivorAlignmentInBytes cause crashes in CMBitMapClosure::do_bit

[Jon Masamitsu]

Reviewed.

Jon

On 01/07/2015 03:02 PM, Stefan Johansson wrote:
> Thanks Jon and Thomas,
>
> On 2015-01-07 23:37, Jon Masamitsu wrote:
>>
>> On 1/7/2015 12:14 PM, Thomas Schatzl wrote:
>>> Hi Jon,
>>>
>>> On Wed, 2015-01-07 at 11:44 -0800, Jon Masamitsu wrote:
>>>> Stefan,
>>>>
>>>> The CR indicates to me that the clearing would be done at the 
>>>> uncommit() but
>>>> this fix has the clearing done at the commit().  Am I reading the 
>>>> CR and
>>>> webrev
>>>> correctly?  If so, the arguments for doing the clearing at the
>>>> uncommit() seem
>>>> good ones.
>>>    Stefan and me talked about the fix again, and somewhat agreed to
>>> implement the "cleaner" way of clearing at commit.
>>>
>>> Clearing at uncommit would be less code, we do not need to keep 
>>> track in
>>> the _needs_clear_at_commit bitmap to avoid the problems with startup
>>
>> I liked that aspect of clear at uncommit.
> Yes, it would be nice not adding another bitmap, but doing so and 
> delaying the clearing also have the nice effect that not all clearing 
> have to be done a once. It will likely be spread out (if not all pages 
> are re-committed at once) or can even avoided (if the page never is 
> committed again).
>>> performance, but then people might notice that heap shrinking (after
>>> full gc, i.e. full gc time is slower) is slower than other collectors
>>> because of that ;)
>>
>> In my observation it is already slower.  The clear_all_count_data() 
>> makes it so.
>> I don't particularly like making it worse but the clear at uncommit 
>> seemed so nice.
>>
>>>
>>> They would probably rather expect this to be done at commit time I 
>>> guess
>>> (regardless of whether the OS or the VM will do that).
>>
>> Agreed.
>>
>>>
>>> This is of course guesswork, we did not measure the difference, just
>>> talked about options how to fix the issue.
>>>
>>> Either way seemed fine to us, this solution is not that much worse in
>>> complexity (even Kim's suggestion probably would not).
>>
>> The current solution requires keeping track of what needs to be 
>> cleared and
>> then remembering to clear it.    I won't object to this solution if 
>> you guys
>> still prefer it.
>>
> Yes, this proposal is a little more complex than doing the clearing at 
> uncommit, but I still prefer this solution since it won't do 
> unnecessary clearing and it allows the clearing to be split up to more 
> that one pause.
>
> Thanks,
> Stefan
>
>> Jon
>>
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>
>