[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