RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v4]

[David Holmes]

On Thu, 3 Jul 2025 03:08:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

Okay - still took me a little while to understand the double-indirection of the "tail ptr" in `add`, but I get it now. So looking at the acquire/release requirements:
- all additions are done with `cmpxchg` which is effectively a release-store
- when you iterate the list all loads of the "next" agent must be a load-acquire, this means
  - when you create the iterator you need a load-acquire (which you have when you pass `head()` )
  - In `Iterator::next()` you need a load-acquire on each read of the `_next` field which is most simply done by defining `JvmtiAgent::next()` as a load-acquire and using that in the iterator code instead of direct field access. 
- `JvmtiAgent::set_next` should be a release-store though as far as I can see it is not used.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2981588585