On Thu, 5 Aug 2021 05:44:18 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> The `_tlist` is a handle that ensures the captured ThreadsList remains live >> while the iterator (or a copy) exists. Dropping it would leave `_it` and >> `_end` potentially dangling. > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/4949
