On Thu, 5 Aug 2021 09:33:34 GMT, David Holmes <dhol...@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
