RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics
Volkan Yazici
vyazici at openjdk.org
Tue Jan 20 18:54:12 UTC 2026
On Tue, 20 Jan 2026 08:27:59 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:
>> src/hotspot/share/opto/opaquenode.hpp line 160:
>>
>>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
>>> 159: // inputs instead).
>>> 160: class OpaqueGuardNode : public Node {
>>
>> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?
>
> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. 🤔
Fair enough — I was just curious.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707418513
More information about the security-dev
mailing list