On Thu, 5 Aug 2021 07:55:59 GMT, Kim Barrett <kbarr...@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
