8076110: VM crash when class is redefined with Instrumentation.redefineClasses

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Fri Jun 12 18:06:24 UTC 2015


On 6/12/15 11:03 AM, Andreas Eriksson wrote:
>
> On 2015-06-12 19:29, serguei.spitsyn at oracle.com wrote:
>> On 6/12/15 4:49 AM, Andreas Eriksson wrote:
>>>
>>>
>>> On 2015-06-12 00:36, serguei.spitsyn at oracle.com wrote:
>>>> On 6/11/15 7:32 AM, Coleen Phillimore wrote:
>>>>>
>>>>>
>>>>> On 6/11/15 7:20 AM, Andreas Eriksson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Deleting the resolution errors from InstanceKlass::deallocate 
>>>>>> contents works, but I'm unsure if the deletion code should be 
>>>>>> placed inside the is_shared() if-block or not.
>>>>>> I don't think that CDS should affect our decision to delete the 
>>>>>> cached resolution errors, but I might be missing something.
>>>>>> Coleen, do you know if it affects anything?
>>>>>
>>>>> The resolution errors aren't shared in the CDS archive so it's 
>>>>> fine to delete them outside the is_shared block.  The other things 
>>>>> are in the archive so have to be excluded.
>>>>>
>>>>> I'm still trying to figure out why deleting them inside 
>>>>> ConstantPool::deallocate_contents() deleted them outside a 
>>>>> safepoint.  I didn't find that code path.
>>>>
>>>> The ConstantPool::deallocate_contents() is called only from the 
>>>> free_metadata(ClassLoaderData* loader_data, T md).
>>>>
>>>> There are just two free_metadata() calls that are related to the 
>>>> ConstantPool::deallocate_contents():
>>>>     classfile/classLoaderData.cpp: 
>>>> MetadataFactory::free_metadata(this, (ConstantPool*)m);
>>>>     oops/instanceKlass.cpp: 
>>>> MetadataFactory::free_metadata(loader_data, constants());
>>>>
>>>
>>> There is at least one more place, in the ClassFileParser destructor, 
>>> at classfile/classFileParser.cpp:4271.
>>> // Destructor to clean up if there's an error
>>> ClassFileParser::~ClassFileParser() {
>>>    MetadataFactory::free_metadata(_loader_data, _cp);
>>> It seems to be called when the parsing has gone wrong, which can 
>>> happen when not at safepoint.
>>> Attached a hs_err where this has happened.
>>
>> Good finding!
>>
>> The ConstantPool::deallocate_contents() does not have a call to the 
>> SystemDictionary::delete_resolution_error() anymore.
>> So, it looks like the crash in the attached hs_err has been already 
>> fixed.
>>
>
> That was a crash that was from one of my experimantal builds while 
> trying to fix this bug.
> I attached the hs_err file just to show what code path was taken to 
> ConstantPool::deallocate_contents() when not at a safepoint.
> Sorry if I was unclear on this.

It is Ok.
This was one of my guesses. :)

Thanks,
Serguei

>
> Thanks,
> Andreas
>



More information about the hotspot-runtime-dev mailing list