RFR: 8049831: Metadata Full GCs are not triggered when CMSClassUnloadingEnabled is turned off
Stefan Karlsson
stefan.karlsson at oracle.com
Thu Jul 10 22:51:25 UTC 2014
On 2014-07-11 00:26, Jon Masamitsu wrote:
>
> On 07/10/2014 05:28 AM, Stefan Karlsson wrote:
>> Dmitry Fazunenko had a couple of offline comments.
>>
>> Latests version:
>> http://cr.openjdk.java.net/~stefank/8049831/webrev.03/
>
> Changes look good.
Thanks.
>
> In the test if there is not enough swap space to allocate
> 32m of metadata, will the test fail?
I guess the JVM will exit with an os::commit_memory error message, if we
really don't have that little memory.
> If yes, do you want it
> to fail in that case?
I think the test will fail in that case, because the expected string
wouldn't be found by the OutputAnalyzer.shouldMatch function call.
StefanK
>
> Jon
>
>>
>> StefanK
>>
>> On 2014-07-10 10:22, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please, review this fix to honor -XX:-CMSClassUnloadingEnabled
>>> correctly in the metadata allocation failure path.
>>>
>>> http://cr.openjdk.java.net/~stefank/8049831/webrev.00
>>> https://bugs.openjdk.java.net/browse/JDK-8049831
>>>
>>> By default, CMS does class unloading after a concurrent marking
>>> cycle. When the amount of metadata hits the high water mark
>>> (capacity_until_GC), a concurrent cycle is initiated, the high water
>>> mark is increased and the thread can proceed with the allocation. If
>>> CMSClassUnloadingEnabled is turned off we don't unload classes after
>>> a concurrent cycle, but instead relies on Full GCs to reclaim
>>> metadata memory. The current code skips triggering a concurrent
>>> cycle if CMSClassUnloadingEnabled is turned off, but it still allows
>>> the high water mark to be increased and the thread can proceed with
>>> the allocation without triggering a Full GC first. This defeats the
>>> entire purpose of the high water mark.
>>>
>>> The suggested fix is to not allow the increase of the high water
>>> mark and the allocation if CMSClassUnloadingEnabled is turned off.
>>>
>>> thanks,
>>> StefanK
>>
>
More information about the hotspot-gc-dev
mailing list