Allow to use rvalue reference (n2027)?

[Kim Barrett]

> On Feb 12, 2020, at 11:58 AM, Liu, Xin <xxinliu at amazon.com> wrote:
> 
> Hi,
> 
> I found that you guys plan to turn on C++14 in JDK-8208089.  Selected features are permitted, eg. constexpr.
> 
> I didn’t find rvalue reference in the permit list.  May I know if hotspot allows it if we eventually turn on -std=c++11 or c++14?
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
> 
> Move semantics can eliminate copys of temporary objects.  An alternative approach is to use dynamic allocation and smart pointer. That approach still copys a lot but are significantly cheaper. IMHO, smart pointers like unique_ptr or shared_ptr are not welcomed, right?
> It’s because they’re in C++ standard library, which hotspot tries to avoid.
> 
> On the other side, I think rvalue reference(n2027) is very portable and reliable now.
> 
> Thanks,
> --lx

The permitted new features listed in JDK-8208089 were my initial
proposal, based on what I thought would be (nearly) immediately useful
in Hotspot code.  In my preliminary experiments with using C++11/14
features I've found a couple more things that perhaps should be added.

Rvalue references and move semantics didn't make my initial cut
because I think they aren't widely applicable to the existing code
base, likely requiring some significant redesign and restructuring to
really be useful.  I know of a couple of places where they probably
would be beneficial, but I'm not sure how much difference they'd make.
I also think that rvalue references and move semantics require some
training / experience to use correctly and effectively.  So in terms
of bang for the buck, this didn't seem worth including immediately.

That said, the explicit intent is that additional features will be
added to the permit list as good use-cases are found and cost-benefit
arguments are made.

Regarding unique_ptr and shared_ptr, the JEP focuses on language
features.  Hotspot has historically avoided using Standard Library
facilities (sometimes for good reason, sometimes arguably not or for
no longer relevant reasons).  I think there will be later discussion
around modifying that stance, probably taking a similar approach of
permitted vs forbidden features, along with usage idioms.  For
example, my experiments suggest we won't want to (indeed, won't be
able to) just directly include a lot of Standard Library headers, but
will want to encapsulate them to some extent.