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

Kim Barrett kbarrett at openjdk.org
Fri May 19 07:24:53 UTC 2023


On Fri, 19 May 2023 05:16:46 GMT, Emanuel Peter <epeter 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.

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

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


More information about the hotspot-dev mailing list