RFR: 8305590: Remove nothrow exception specifications from operator new [v2]

Afshin Zafari duke at openjdk.org
Wed Apr 19 10:25:53 UTC 2023


On Tue, 18 Apr 2023 18:29:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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/memory/allocation.hpp line 289:
> 
>> 287:   void* operator new [](size_t size) throw() = delete;
>> 288:   void  operator delete(void* p) = delete;
>> 289:   void  operator delete [](void* p) = delete;
> 
> Making these deleted functions public might provide better error messages if someone accidentally attempts to reference them.

Done.

> src/hotspot/share/memory/allocation.hpp line 504:
> 
>> 502:   // Arena allocations
>> 503:   void* operator new(size_t size, Arena *arena);
>> 504:   void* operator new [](size_t size, Arena *arena) = delete;
> 
> `operator new[](size_t)` (down below, where github won't let me comment directly) should also have it's nothrow exception-spec removed.

Done.

> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114:
> 
>> 112: 
>> 113:   // Non-aborting operator new
>> 114:   void* operator new(size_t size) {
> 
> This change is incorrect, as this can quite obviously return null.  And that seems to be intentional.
> Presumably the callers are checking for a possible null allocation result (else there is a bug).  I think
> it would be less confusing if this took a `std::nothrow_t` to be explicit about it's behavior, and updated
> the caller(s) accordingly.  That would match the usual idiom.

no throw argument is added to the declaration and the caller is changed accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171133732
PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171134794
PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171136374


More information about the serviceability-dev mailing list