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

[Kim Barrett]

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?

It depends on the class whether a simple shallow-copy (the default) is an
adequate move. The main question is whether the destruction of the moved-from
object might damage/delete something that was pilfered for use in the moved-to
object. Since from a quick skim it looked like the destructors for all of the
classes being given move constructors are empty or (implicitly) defaulted, I
think that shouldn’t be a problem. But someone should check them more
carefully. In particular, are there any bases or nested members with
non-trivial destructors?

The problem with std::move is that one can convert an lvalue to an rvalue,
move construct from the rvalue, and then try to use both the old lvalue
(potential UB) and the newly moved-to object, even though they share state
(source of UB). (Also remember that std::move is basically just a convenience
wrapper over a cast of an lvalue to an rvalue - there’s nothing magic about
it. But we’re not doing that anywhere either.)

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

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