RFR: 8049831: Metadata Full GCs are not triggered when CMSClassUnloadingEnabled is turned off
Stefan Karlsson
stefan.karlsson at oracle.com
Mon Aug 4 13:01:23 UTC 2014
Hi again,
I missed running hg add on the test so I'll have to push it as a
separate changeset.
It wil be pushed as:
http://cr.openjdk.java.net/~stefank/8051883/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8051883
thanks,
StefanK
On 2014-07-10 11:38, Stefan Karlsson wrote:
> Hi all,
>
> I decided to convert my adhoc test into a jtreg test that could be
> checked in:
> http://cr.openjdk.java.net/~stefank/8049831/webrev.01
>
> 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