8213481: [REDO] Fix incorrect copy constructors in hotspot
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Tue Nov 27 11:51:18 UTC 2018
Hi,
I built aix slowdebug, fastdebug and product builds successfully.
The other builds run tonight.
Best regards,
Goetz.
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Tuesday, November 27, 2018 9:10 AM
> To: 'Kim Barrett' <kim.barrett at oracle.com>; hotspot-dev developers
> <hotspot-dev at openjdk.java.net>
> Subject: RE: 8213481: [REDO] Fix incorrect copy constructors in hotspot
>
> 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).
More information about the hotspot-dev
mailing list