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