RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]

[David Holmes]

On Thu, 5 Aug 2021 09:24:13 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> This isn't a change wrto StackObj usage. This adapter class used to have a member that was a JavaThreadIteratorWithHandle (the WithHandle class for the same reason the new code has a ThreadsListHandle, to keep the associated ThreadsList alive), which also derives from StackObj.
>> 
>> Personally, I want to agree with you. I would (and do) use StackObj far more sparingly than it appears in our code base. But I've had this same argument with other folks. The de facto situation, so far as I understand it, is that deriving from StackObj documents normal usage. It has no operational behavior or additional semantics, other than attempting to prevent heap allocation (and it doesn't really succeed there, since a derived class could override that behavior, though I don't currently know of any that do so).  That seems to be what some people want from it and think is useful, and I've stopped trying to convince them otherwise.
>
> The adapter is only used as a stack-allocated object, so it can be decorated with StackObj to better communicate this intent.

Ah I didn't realise JTIWH was also stackObj.

The thing with StackObj to me is that it indicates a local object that does something interesting on construction and then also on destruction (eg. like MutexLocker). So having one as a member where the destruction is not related to a stack scope seems odd to me. But a stackObj member in a stackObj class seems more reasonable.

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

PR: https://git.openjdk.java.net/jdk/pull/4949