RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Apr 9 22:47:03 UTC 2014

Hi Volker

I am worried about ALLOW_OPERATOR_NEW_USAGE change.
I read https://bugs.openjdk.java.net/browse/JDK-8012902 and I think 
runtime group should do review of these changes and test them.

You can use fatal(msg) instead of guarantee(false, msg).


On 4/9/14 9:34 AM, Volker Simonis wrote:
> Hi,
> could you please review and sponsor the following small change:
> http://cr.openjdk.java.net/~simonis/webrevs/8039805/
> https://bugs.openjdk.java.net/browse/JDK-8039805
> which fixes the signature of the global new/delete operators in allocation.cpp
> For non-product builds allocation.cpp defines global new/delete
> operators which shut down the VM if they get called at runtime. The
> rational behind this is that the these global operators should never
> be used in HotSpot.
> Unfortunately, the signature of some of these operators doesn't
> conform to the C++ standard which confuses some C++ compilers. For a
> more detailed explanation of the C++ background of this issue see the
> new comments in allcoation.cpp and the end of this mail.
> This change also replaces the asserts in the operators with guarantees
> because the code may also be active in not-product (aka. 'optimized')
> builds.
> Finally, the webrev fixes two places in the AIX-port which used the
> global new operator. After the change we can now remove the definition
> of ALLOW_OPERATOR_NEW_USAGE from aix/makefiles/vm.make.
> I have also removed ALLOW_OPERATOR_NEW_USAGE from
> bsd/makefiles/vm.make and the corresponding comments in allcoation.cpp
> which state that on Mac OS X the global new/delete operators from the
> HotSpot cause problems together with usages of these operators from
> the class library such as the ones from
> Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair. I couldn’t
> observe any such problems but if anybody has some concrete concerns
> I'm ready to remove this part from the webrev.
> I've build and tested these changes on Linux/x86_64, Linux/ppc64,
> Solaris/Sparc, Windows/x86_64, MacOS X and AIX/ppc64. I've especially
> run the regression tests from sun/security/ec which exercise the
> method Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair which
> was mentioned to cause problems in conjunction with the globally
> defined new/delete operators from the HotSpot but couldn't see any
> issues, neither in the slowdebug nor in the optimized build.
> Following some C++ background regarding the global new/delete operators:
> In C++98/03 the throwing new operators are defined with the following signature:
> void* operator new(std::size_tsize) throw(std::bad_alloc);
> void* operator new[](std::size_tsize) throw(std::bad_alloc);
> while all the other (non-throwing) new and delete operators are
> defined with an empty throw clause (i.e. "operator delete(void* p)
> throw()") which means that they do not throw any exceptions (see
> section 18.4 of the C++ standard
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf).
> In the new C++11/14 standard
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf),
> the signature of the throwing new operators was changed by completely
> omitting the throw clause (which effectively means they could throw
> any exception) while all the other new/delete operators where changed
> to have a 'nothrow' clause instead of an empty throw clause.
> Unfortunately, the support for exception specifications among C++
> compilers is still very fragile. While some more strict compilers like
> AIX xlC or HP aCC reject to override the default throwing new operator
> with a user operator with an empty throw() clause, the MS Visual C++
> compiler warns for every non-empty throw clause like
> throw(std::bad_alloc) that it will ignore the exception specification
> (see http://msdn.microsoft.com/en-us/library/sa28fef8.aspx).
> I've therefore changed the operator definitions such that they
> correctly work with all currently supported compilers and in way which
> should be upwards compatible with C++11/14.
> Please notice that I'm aware of the discussion around "8021954: VM
> SIGSEGV during classloading on MacOS; hs_err_pid file produced"
> (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/thread.html#8924,
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9758d9f36299)
> which introduced empty throw() clauses on all user defined new
> operators. But I think the rational used for that change doesn't apply
> here, because these global, user user defined new operators changed in
> this webrev aren't meant to be really used. There only task is to
> override the default, global operators (and therefore they need to
> have the right signature) and to shut the VM down if they get called.
> Thank you and best regards,
> Volker

More information about the hotspot-dev mailing list