[code-reflection] RFR: HAT memory mallocs and copies improved [v2]
Juan Fumero
jfumero at openjdk.org
Mon Dec 15 09:47:25 UTC 2025
On Fri, 12 Dec 2025 17:31:32 GMT, Gary Frost <gfrost at openjdk.org> wrote:
>> Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:
>>
>> [hat] life-example revert control to RO
>
> hat/backends/ffi/cuda/src/main/native/cpp/cuda_backend.cpp line 366:
>
>> 364: CudaBackend::CudaBuffer *CudaBackend::getOrCreateBuffer(BufferState *bufferState, u8_t accessor) {
>> 365: CudaBuffer *cudaBuffer = nullptr;
>> 366: if (bufferState->vendorPtr == nullptr || bufferState->state == BufferState::NEW_STATE) {
>
> So I understand we are embedding the access (RO|WO etc) in the buffer...
>
> we get this access from the arg slot info (RO|WO etc) and then putting this in the memory segment..
>
> What if we pass this to another kernel whose access is different?
Accesses declared from the API side are immutable. In the case it changes it should be declared as R/W. The copy on-demand will work because it takes the access for the arg slot. We can revisit this model. Note that, if a buffer is Read-only, later we can't change it, unless we do a new malloc and move the data to the new buffer. But this is very inefficient. So, if this is what we want, we need to find other options.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/746#discussion_r2618694305
More information about the babylon-dev
mailing list