RFR: 8339725: Concurrent GC crashed due to GetMethodDeclaringClass [v10]
David Holmes
dholmes at openjdk.org
Wed Sep 11 12:21:09 UTC 2024
On Wed, 11 Sep 2024 10:23:49 GMT, Liang Mao <lmao at openjdk.org> wrote:
>> Hi,
>>
>> It's a fix for 8339725. I think getting the oop from Klass::java_mirror() should use a ON_PHANTOM_OOP_REF decorator here which could make sure the oop would be kept alive in concurrent marking and return nullptr while in concurrent reference processing and unloading.
>>
>> test/hotspot/jtreg/runtime and gc are clean.
>>
>> Thanks,
>> Liang
>
> Liang Mao has updated the pull request incrementally with one additional commit since the last revision:
>
> use -Xmx50m to increace the crash posibility
FWIW I don't think resurrecting the dying oop is the right way to fix this given that the underlying problem is that the application failed to keep the class of the jMethodID alive. Can't we detect it is dying (obviously more that what `is_alive` does) and just act as-if it were already dead? There is an inherent race here so the application can't rely on this act of resurrection anyway.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20907#issuecomment-2343512440
More information about the hotspot-dev
mailing list