RFR: 8062063: Usage of UseHugeTLBFS, UseLargePagesInMetaspace and huge SurvivorAlignmentInBytes cause crashes in CMBitMapClosure::do_bit
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:
>> 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
>> 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).
> 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.
More information about the hotspot-gc-dev