Segfault in CompiledMethod::is_unloading()

Erik Österlund erik.osterlund at oracle.com
Mon Nov 19 16:54:37 UTC 2018


Hi,

Verified my hypothesis, and it was correct. Will send out fix under 8213486.

Thanks,
/Erik

On 2018-11-16 18:47, Erik Österlund wrote:
> Hi Andrew,
>
> On 2018-11-16 18:07, Andrew Haley wrote:
>> On 11/16/18 12:51 PM, Erik Österlund wrote:
>>> By the look of it, the fact that you are crashing there means that it
>>> was not been visited for your AoT method, and when the sweeper tries
>>> calling it, it needs to compute the value and has no means of doing 
>>> that
>>> any longer (it should already have been computed). I guess I must have
>>> messed up the assumption that all compiled methods are walked during
>>> code cache unloading in the case of AoT. Sorry about that.
>>
>> OK, thanks. Given that this is a crasher on AOT-compiled code and
>> there's no workaround at present, I guess it has to be fixed. I'm
>> not really clear how it should be fixed, though: do we really want
>> to walk all AOT-compiled methods during code cache unloading?
>>
>
> We have to walk all is_alive() AOT-compiled code during code cache 
> unloading for two reasons:
>
> 1) To compute is_unloading
> 2) To clean inline caches referring to compiled methods that died due 
> to unloading.
>
> By moving the CompiledMethod::is_unloading() logic to 
> nmethod::is_unloading() and have AotCompiledMethod::is_unloading() 
> simply return false, the first reason would become invalid. But I 
> think we still need to walk all is_alive() AotCompiledMethods to clean 
> their inline caches. But if my theory is right about what is going on 
> here, then it might at least solve this bug.
>
> /Erik



More information about the hotspot-gc-dev mailing list