RFR: 8302670: use-after-free related to PhaseIterGVN interaction with Unique_Node_List and Node_Stack [v10]

[Emanuel Peter]

On Fri, 19 May 2023 07:22:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> OTOH, I think the rationale of needing a move constructor to permit returning noncopyable objects from functions is eliminated by C++17's guaranteed copy elision.
>> 
>> @kimbarrett @jcking I wonder if it is not better to just avoid any move constructors/assign. We would have to convert the "return value optimization" cases (i.e. return contrainer by value, and it being captured by the move constructor), and instead create containers outside, and pass them in as references ("pseudo-output"). It is a bit ugly, but maybe more understandable than the move semantics?
>> 
>> Once we'd take on C++17, we can still reconsider changing patterns and returning containers with the guaranteed copy elision.
>
>> > OTOH, I think the rationale of needing a move constructor to permit returning noncopyable objects from functions is eliminated by C++17's guaranteed copy elision.
>> 
>> @kimbarrett @jcking I wonder if it is not better to just avoid any move constructors/assign. We would have to convert the "return value optimization" cases (i.e. return contrainer by value, and it being captured by the move constructor), and instead create containers outside, and pass them in as references ("pseudo-output"). It is a bit ugly, but maybe more understandable than the move semantics?
>> 
>> Once we'd take on C++17, we can still reconsider changing patterns and returning containers with the guaranteed copy elision.
> 
> I'm not generally much of a fan of out-ref parameters.
> 
> I see the move constructors in this PR as being workarounds for our _current_
> lack of C++17 guaranteed copy elision. So I would be okay with keeping them,
> with an RFE to remove them once they are no longer needed (i.e. we're using
> C++17 or later). Label that RFE with `cpp17`. (That's a new label; we have
> `cpp14` and `cpp20` but nothing with `cpp17` yet).
> 
> Ignore my comment about move-assign operators for now, and don't bother with
> them unless and until actually needed (which might be never).  There's no
> deprecation warning issue related to not having them.

@kimbarrett @jcking So if we never use `std::move` (currently not used at all in the HotSpot code), do I actually need to have a custom implementation of the move-constructor, or is the `default` enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/13833#issuecomment-1554263479