Allow to use rvalue reference (n2027)?

[Liu, Xin]

Hi, Kim, 

I got it. It depends on good use-cases.  It turns out my use case is not.  I use raw pointers and arena to avoid copying. 
Thank you for the extensive explanation. 

Thanks,
--lx

On 2/13/20, 7:27 PM, "Kim Barrett" <kim.barrett at oracle.com> wrote:

    > 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.