[code-reflection] RFR: Improved error message on OpenCLBackend if Reflect annotation is missing on transitive methods from kernel method
Gary Frost
gfrost at openjdk.org
Thu Jan 1 23:09:32 UTC 2026
On Thu, 1 Jan 2026 22:59:44 GMT, Nadeesh TV <ntv at openjdk.org> wrote:
>> I was looking at this today.
>>
>> My guess is that the BufferTagger has all the information we need for this. It already attempts to inline all the kernel callgraph so that it can analyse buffer accesses.
>>
>> To do this it is pulling the CodeModels of reachable methods as it inlines. I suspect that there is a 'dangling' else in there that is allowing us to progress if a code model could not be located.
>>
>> It's a recursive inliner (using nested code reflection transformers), and is fairly compact. But I suspect this is a good place to look.
>
>>I suspect that there is a 'dangling' else in there that is allowing us to progress if a code model could not be located.
>
> Problem is that there is no [else](https://github.com/openjdk/babylon/blob/code-reflection/hat/core/src/main/java/hat/BufferTagger.java#L81) . We inline functions that have code model available and ignoring the other case. Therefore, there also it's the same issue . InvokeOp like `hat.buffer.S32Array::array(long)` etc. will reach the else part and thus we need a criteria to differentiate between `hat.buffer.S32Array::array()` and `squareitWithoutReflectAnnotation`.
On my phone, so analysis limited.
Look at the conditional on line 70 (BufferTagger) it is looking for methods with a code model.... it has no else... my guess is we can detect a call for which we can resolve a Java.lang.rflect.Method... but which has no CodeModel....
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/798#discussion_r2656663025
More information about the babylon-dev
mailing list