[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