[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