[code-reflection] RFR: Improved error message on OpenCLBackend if Reflect annotation is missing on transitive methods from kernel method

[Gary Frost]

On Wed, 31 Dec 2025 15:23:31 GMT, Nadeesh TV <ntv at openjdk.org> wrote:

>> Will look at the delete Q. You may be correct. 
>> 
>> Howver, we should not defer testing this until we get to ffi/cpp native code. This is detectable in the Java side way before we get to first kernel dispatch.  
>> 
>> If we go down this rabit hole we are forced to also do this in the CUDA/PTX and all future ffi implementations.
>
> Agree with you that we should detect this earlier and bail out.
>>This is detectable in the Java side way before we get to first kernel dispatch.
> 
>  Since kernel method can contain call to other methods which also does not have **@Reflect** but at the same time won't run into the same issue,  what criteria  could we use here? 
>  I could only think of using the class name of the method  as the criteria - for eg: if the class name of the method is not from jdk/hat package and if annotation is missing on that method then throw error but it seems too brittle.

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.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/798#discussion_r2656579316