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

Jon Masamitsu jon.masamitsu at oracle.com
Wed Jan 7 22:37:39 UTC 2015


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

Jon

>
> Thanks,
>    Thomas
>
>



More information about the hotspot-gc-dev mailing list