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

[Coleen Phillimore]

On Thu, 5 Aug 2021 09:33:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JfrThreadIterator is only used as a stack-allocated object, so it and the adapters can be decorated with StackObj to better communicate this intent. The AP (Allocation Policy) policy in JfrThreadIterator can be removed and the JfrThreadIterator can be decorated with StackObj (unconditionally). Depends on how much you want to spend on this (I would guess minimal). But in actual usages, the iterators and adapters are de-facto StackObj already.
>
> 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.

StackObj to me communicates intent. I don't have to look for "new SomeClass" to see how it is allocated and deallocated, since the new and delete operator are private and won't compile.  Same is true for AllStatic.  I'm one that hasn't been convinced otherwise.  I'm not totally intransigent though as i approved the removal of ValueObj. So there's that.

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

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