8213481: [REDO] Fix incorrect copy constructors in hotspot

[Lindenmaier, Goetz]

Hi Kim, 

I put this into our build system to assure our compilers grok this code.
AIX is building already, all other platforms will build tonight 
(European night��).  I think xlc is the most likely to cause issues, 
On linux we are on gcc 7.3 anyways, which should be fine.

Best regards,
  Goetz.





> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Kim Barrett
> Sent: Monday, November 19, 2018 7:14 AM
> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: RFR: 8213481: [REDO] Fix incorrect copy constructors in hotspot
> 
> Please review this fix of the debug-only copy constructor and
> assignment operator for ResourceObj, along with adding some missing
> uses of the copy constructor.
> 
> The missing copy constructor uses were found by enabling -Wextra.
> 
> The ResourceObj debug-only copy constructor should behave exactly the
> same as the corresponding default constructor.  That is, the setup for
> checking the allocation state in the destructor and operator delete
> should be the same whether in the normal or copy constructor.  That
> previously wasn't true, resulting in assert failures.
> 
> 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.
> 
> Note that the ResourceObj allocation/construction/deletion code is
> oddly indented, using an initial 4 space indentation and 2 spaces for
> further indenting, unlike the usual consistent 2 space indentation
> used elsewhere in HotSpot, including elsewhere in allocation.cpp.
> I've left that indentation intact to minimize diffs in some views for
> review.  Unless there are objections, I plan to fix the indentation.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8213481
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8213481/open.00/
> 
> Testing:
> mach5 tier1-3.  There were many failures in these tiers with just the
> addition of the missing copy constructor calls (JDK-8213414).