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 Thanks for the explanations.

All of the containers in question are subclasses from `AnyObj`:

AnyObj -> Dict
AnyObj -> VectorSet
AnyObj -> Node_Array -> Node_List -> Unique_Node_List


`AnyObj` does have a destructor, it overwrites some internal addresses with `badHeapOopVal`. I'm not sure about this, but maybe that is ok? `VectorSet` has an empty destructor, so that should be ok. `Dict` as well. `Node_Array`, `Node_List` and `Unique_Node_List` have the implicit destroctor. And I think shallow copies of everything is ok.

I tried to still implement proper move-constructors for the 5 containers. `Dict`, `VectorSet` and `Node_Array` was relatively straight forward. But for `Node_List` and `Unique_Node_List` I think I would have to call the suberclass (baseclass) move-constructor, so that the corresponding fields of the superclasses are also handled. But for that, I would have to explicitly use `std::move` on the baseclass. That would be a first in the whole code-base. And I'd have to `#include <utility>`.

So is it really worth it to implement the move-constructors, just to `nullptr` out some fileds? Or should I just do it where it is easy, and leave the rest? Or just leave them all default?
@kimbarrett @jcking do you have any better alternative?

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

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