RFR: 8356693: AOT assembly phase fails with -javaagent
Ioi Lam
iklam at openjdk.org
Wed May 14 16:07:50 UTC 2025
On Wed, 14 May 2025 02:21:39 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:
>>> Instead of intercepting here would it be better if we can clear `JvmtiAgentList::_list` in `CDSConfig::check_aotmode_create()`?
>>
>> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
>>
>> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
>>
>> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.
>
>> That's what I had in an earlier version, but then there's no code to free the allocated entries, and I am too lazy to write the deallocator.
>>
>> Either way the effect is the same. The trivial amount of memory used by the entries are not reclaimed, but the VM will exit after a finite amount of time anyway, after the cache creation is finish.
>>
>
> It looks like the memory for these entries is never freed even after unloading the agents during shutdown. So there memory is never reclaimed. And setting `JvmtiAgentList::_list` to nullptr is not really changing that behavior.
>
>> I thought intercepting it here is a bit cleaner and avoids the awkward question of freeing the entries.
>
> hmmm...not sure about that. Ideally we should ignore the jvmti options that add agents if the JVM is in assembly phase. But we detect the assembly phase after jvmti options have been processed.
> IMO clearing the _list is the next best approach. If that doesn't work then more intrusive fix like intercepting the `JvmtiAgentList::Iterator`.
I cleared the `_list` as you suggested.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25170#discussion_r2089285551
More information about the hotspot-dev
mailing list