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

[Markus Grönlund]

On Thu, 5 Aug 2021 07:55:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Okay I had assumed there was a ThreadsList/Handle in the enclosing scope that was being used to initialize this and keep things live, but that is not the case.
>> I still think it makes no sense to have a StackObj subtype as a member though. Maybe ThreadsListHandle should no longer be a StackObj ?
>
> 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.

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

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