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

[Emanuel Peter]

On Fri, 19 May 2023 20:10:27 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.
>> 
>> 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.)

@kimbarrett I quote you from the slack conversation:
> “Invalidating” the moved-from object to protect against someone using std::move (which at least for now we don’t do) and then doing something they aren’t supposed to do doesn’t seem like a good path to me. Anyone using std::move is taking responsibility for not doing anything they shouldn’t with the moved-from object. Also remember that the move constructors in question are a workaround for not having C++17.  I think it is likely that we’ll have C++17 before we start making any use (or at least any significant use, e.g. beyond things like the constructor chaining in your example) of std::move.

I will hence just keep the `default` move constructors, but and `delete` the move assign operators.

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

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