RFR: 8213481: [REDO] Fix incorrect copy constructors in hotspot

[Kim Barrett]

> On Nov 26, 2018, at 10:21 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 27/11/2018 1:15 pm, Kim Barrett wrote:
>>> On Nov 26, 2018, at 8:39 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> The ResourceObj assignment operator also should not be assuming the
>>>> target of the assignment was stack/embeded allocated; that's just not
>>>> a valid assumption.  The corresponding assertion has been removed.
>>> 
>>> Isn't that enforcing a usage requirement of ResourceObj? C-heap/resource-area/arena allocated ResourceObj should only be used via pointers - assigning one to another makes no sense to me.
>> I don’t see any reason for such an artificial restriction, and think it might prevent reasonable uses.
>> I don’t have a specific use-case in mind, but the natural result is observed from doing the natural thing.
> 
> What is the "natural result" here? I don't see (and Vladimir seems to share a similar view) how it makes any sense to assign non stack/embedded resource objects to each other?  And mixing assignment across different types of ResourceObj makes no sense to me at all. I'm not even sure there's a usecase for stack/embedded but that at least seem a consistent usage.
> 
> David

The "natural result" is that the derived class copy-assign code does
what it does.  There are things that can go badly wrong here regarding
lifetimes of embedded object references.  But the asserted restriction
on the allocated location of the object being copy-assigned to does
nothing that I can see to prevent those potential problems.

Can you provide a use-case where the assertion actually does something
useful?  I removed it because I don’t think such a thing exists.