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

[Stefan Johansson]

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
>>
>>
>