[code-reflection] RFR: Model verifier

Paul Sandoz psandoz at openjdk.org
Thu Oct 10 18:55:37 UTC 2024


On Wed, 2 Oct 2024 15:09:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch starts work on model `Verifier` and implements following verifications:
>  - operands declaration dominance
>  - `BranchOp` reference arguments matching target block parameters (simple matching by `TypeKind` with erased `int` sub-types)
>  - `ArithmeticOperation`, `TestOperation` and `ConvOp` verified presence of relevant method handler in `InvokableLeafOps`
>  
> `TestSmallCorpus` is improved to verify code model.
> 
> Fixes of bugs newly discovered by the `TestSmallCorpus`:
>  - missing methods in `InvokableLeafOps`
>  - `Interpreter` use of provided lookup for `resolveToMethodType`
>  - `Interpreter` erase  sub-`int` types for `InvokeOp` execution + added `TestLiftCustomBytecode::testEraseInts`
> -  Removed complex sub-`int` types calculation from `BytecodeLift` and `LocalsToVarMapper` 
> - `BytecodeLift` fixed to avoid production of some obsolete block parameters

src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java line 424:

> 422:             MethodHandle mh = resolveToMethodHandle(il, co.invokeDescriptor(), co.invokeKind());
> 423:             Object[] values = o.operands().stream().map(oc::getValue).toArray();
> 424:             target = eraseInts(mh.type(), target, values);

Can you provide an example of why this is required? I think i can guess based on changes to the lifter. Can this impact other areas too like field and array access?

I think in general we have to be careful here. The properties of lifted models are having a broader impact. Arguably, this could be a code model transformation instead.

Terminology-wise "erase" is reserved for references. IIUC correctly we are operating on values of basic primitive types and i believe converting to them non-basic types based on corresponding method parameter types.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/247#discussion_r1795941899


More information about the babylon-dev mailing list