On Thu, 5 Aug 2021 09:24:13 GMT, Markus Grönlund <mgron...@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
