On Wed, 19 Apr 2023 10:25:49 GMT, Afshin Zafari <d...@openjdk.org> wrote:
>> - The `throw()` (i.e., no throw) specifications are removed from the
>> instances of `operator new` where _do not_ return `nullptr`.
>>
>> - The `-fcheck-new` is removed from the gcc compile flags.
>>
>> - The `operator new` and `operator delete` are deleted from `StackObj`.
>>
>> - The `GrowableArrayCHeap::operator delete` is added to be matched with its
>> corresponding allocation`AnyObj::operator new`, because gcc complains on
>> that after removing the `-fcheck-new` flag.
>> - The `Thread::operator new`with and without `null` return are removed.
>>
>> ### Tests
>> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1
>> mach5: tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8305590: Remove nothrow exception specifications from operator new
src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114:
> 112:
> 113: // Non-aborting operator new
> 114: void* operator new(size_t size, const std::nothrow_t&
> nothrow_constant) throw() {
Hm, now I'm wondering why isn't an `operator delete` to go with this? Or are
these objects
never deleted? Otherwise I'd have thought we'd get the same mismatched
new/delete warning
you encountered elsewhere. If they're never supposed to be deleted, then
giving `operator delete`
a deleted definition here seems appropriate, to prevent accidentally calling
the CHeapObj function.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171175550
