On Tue, 30 Jul 2024 05:27:37 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Please review this change that removes some uses of literal 0 as a null
>> pointer constant in prims code.
>>
>> Testing: mach5 tier1
>
> src/hotspot/share/prims/jni.cpp line 1151:
>
>> 1149: \
>> 1150: EntryProbe; \
>> 1151: ResultType ret{}; \
>
> This looks bogus. ResultType is just a macro variable and could be a
> primitive type. ?? Does the local need initializing?
This is value-initialization syntax. Value-initialization of a primitive type
is zero-initialization.
However, I think we don't need the local variable at all. Here and in the
other 5(?) similar places, rather than
ResultType ret{};
...
ret = jvalue.get_##ResultType();
return ret;
I think we could just have
...
return jvalue.get_##ResultType();
> src/hotspot/share/prims/methodHandles.cpp line 439:
>
>> 437: default:
>> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid),
>> vmIntrinsics::name_at(iid));
>> 439: return 0;
>
> Do we no longer need these returns after `fatal` to keep compilers happy?
Now that we have, and are using, `[[noreturn]]` on all platforms, we no longer
need that dead code.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408217
PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408335
