RFR: 8213481: [REDO] Fix incorrect copy constructors in hotspot
vladimir.kozlov at oracle.com
Tue Nov 27 00:24:37 UTC 2018
I am fine with changes for copy constructor.
Do we have other cases where it is used? I think the original use in  could be removed because I doubt the hack will
have performance benefits for such big methods as stated in comment. May be we would not need it copy constructor then.
For assignment operator I have reservation. You can't use original allocation type if you can't guaranty that
destination is the same type.
On 11/18/18 10:14 PM, Kim Barrett wrote:
> 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.
> mach5 tier1-3. There were many failures in these tiers with just the
> addition of the missing copy constructor calls (JDK-8213414).
More information about the hotspot-dev