Lifetime of SVM allocations in memory objects

[bashbaug]

From a discussion in the October 14th memory subgroup:

If an application allocates SVM memory by calling clSVMAlloc, then wraps the SVM allocation in an OpenCL memory object by passing the pointer to SVM memory as the host_ptr argument to clCreateBuffer with CL_MEM_USE_HOST_PTR, what is the lifetime of the allocated SVM memory?

Specifically:

1. Is the SVM allocation treated similar to an ordinary host allocation, meaning that the allocation cannot be freed until the memory object is destroyed? Similar to ordinary host allocations, applications might use clSetMemObjectDestructorCallback to know when the memory object is destroyed and hence it is safe to free the underlying SVM allocation.

2. Or, is the SVM allocation treated specially because the implementation could know that the passed-in host_ptr is an SVM allocation and therefore extend the lifetime of the SVM allocation beyond when the application frees the underlying SVM allocation? In this case, the application could safely call clSVMFree immediately after creating the memory object.

I did a quick search through the OpenCL spec and I can't find any place where this scenario is described explicitly. Because the description of clSetMemObjectDestructorObject does not distinguish between the ordinary host pointer case and the SVM allocation case, though, perhaps that's a hint towards (1).

(1) is certainly the safer of the two options, since it is valid and correct even if an implementation does (2), whereas an application relying on (2) runs the risk of a use-after-free if the implementation assumes (1).

[bashbaug]

Discussed in the October 21st teleconference.

We didn't find anyplace hinting that the answer is anything other than (1), and this is what implementations are doing.

Leaving this issue open to potentially clarify the spec. Note, any clarifications will occur in the main spec, unrelated to unified SVM, and unified SVM will simply inherit this behavior.