On Tue, 22 Apr 2025 18:23:52 GMT, John R Rose <jr...@openjdk.org> wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refine validation and defensive copying
>
> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
> line 58:
>
>> 56: * The HotSpot VM checks, when loading a class, the consistency of
>> recognized
>> 57: * methods and {@code @IntrinsicCandidate} annotations, unless the {@code
>> 58: * CheckIntrinsics} VM flag is disabled.
>
> <p>
> Even if an intrinsic is available the VM is not obligated to use it. For
> example,
> the bytecodes of an intrinsic method may be executed by lower tiers of VM
> execution, while higher tiers may replace the bytecodes with specialized
> assembly code and/or compiler IR. Therefore, intrinsic implementors must
> ensure that non-bytecode execution has (in an application-specific sense)
> the same results as execution of the actual Java code. Also, persons not
> directly involved with maintaining the Java libraries or the HotSpot VM can
> usually ignore the {@code @IntrinsicCandidate} annotation, when reasoning
> about the actions of the method. Such persons must not assume, however,
> that checks for nulls, out-of-bounds indexes, and wrong types will be
> performed
> by the intrinsic, even though normal Java execution always performs such
> checks.
And for arrays, a footnote might be appropriate:
<p>
For some highly optimized algorithms, it may be impractical to ensure that array
data is read or written only once by the intrinsic. If the caller of the
intrinsic
cannot guarantee that such array data is unshared, then the caller must also
document the effects of race conditions on it. (Such a race occurs when another
thread writes the array data during the execution of the intrinsic.) For
example,
the documentation can simply say that the result is undefined if a race happens.
And maybe, after that, something more about type safety:
<p>
In no case may any intrinsic be allowed to perform an operation that fails to be
type safe. It must not indirect a null pointer; it must not access a field or
method
on an object which does not possess that field or method; it must not access
an element of an array not actually present in the array; and it must not
manipulate managed references in a way that prevents the GC from managing
them. The caller of the intrinsic is fully responsible for preventing every
kind
of type safety violation, in the case (the common case) that the intrinsic
itself
does not itself somehow prevent the violation.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054665206
