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