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

Nadeesh TV ntv at openjdk.org
Wed Dec 31 15:26:24 UTC 2025


On Wed, 31 Dec 2025 14:06:58 GMT, Gary Frost <gfrost at openjdk.org> wrote:

>> hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend.cpp line 223:
>> 
>>> 221:                 std::cerr << "clGetBuildInfo (getting log) failed" << std::endl;
>>> 222:                 delete[] log;
>>> 223:                 log = nullptr;
>> 
>> @grfrost Not sure whether this delete was really needed. 
>> If I understood correctly, the destructor of `OpenCLProgram`  should do this anyway, hence removed. But if you think otherwise let me know.
>
> 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.

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

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


More information about the babylon-dev mailing list