RFR: 8062063: Usage of UseHugeTLBFS, UseLargePagesInMetaspace and huge SurvivorAlignmentInBytes cause crashes in CMBitMapClosure::do_bit
jon.masamitsu at oracle.com
Thu Jan 8 16:08:17 UTC 2015
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:
>>>> 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.
> 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
>>> (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.
> 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.
More information about the hotspot-gc-dev