RFR (S) 8181170: resolved_references array leaks for RedefineClasses
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Aug 29 18:04:21 UTC 2017
On 8/29/17 1:13 PM, Jiangli Zhou wrote:
> Hi Coleen,
>
> This looks good to me. The InstanceKlass::deallocate_contents() takes
> care of the shared case and only
> calls MetadataFactory::free_metadata(loader_data, constants()) if the
> constants !is_shared(). So, we don’t need to worry about any possible
> side effect of calling G1SATBCardTableModRefBS::enqueue() on archived
> resolved_references object. Just to be safe, how about adding an
> assert in ConstantPoolCache::deallocate_contents() to make sure the
> current cache is !is_shared()? No need for a new webrev if you decide
> to add the assert.
Yes, I thought of that too - I'll add it.
Thanks for the code review.
Coleen
>
> void InstanceKlass::deallocate_contents(ClassLoaderData* loader_data) {
> ...
> if (constants() != NULL) {
> assert (!constants()->on_stack(), "shouldn't be called if anything
> is onstack");
> if (!constants()->is_shared()) {
> MetadataFactory::free_metadata(loader_data, constants());
> }
>
>
> Thanks,
> Jiangli
>
>> On Aug 29, 2017, at 7:01 AM, coleen.phillimore at oracle.com
>> <mailto:coleen.phillimore at oracle.com> wrote:
>>
>> Summary: clear out resolved_reference from ClassLoaderData::_handles
>>
>> See the bug for details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev
>> <http://cr.openjdk.java.net/%7Ecoleenp/8181170.01/webrev>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8181170
>>
>> Tested with:
>> tier1 hotspot (includes most hotspot jtreg tests)
>> tonga nsk.jvmti, nsk.jdi (internal tests)
>> jdk/test/java/lang/instrument
>> jdk/test/com/sun/jdi
>>
>> Thanks,
>> Coleen
>>
>>
>
More information about the hotspot-dev
mailing list