Previously, ArrayHandleVirtual was using the default Transfer object.
This was problematic because it would copy/allocate things in the
execution environment independently from the array that it was wrapped
around. This caused several negative effects, particularly for CUDA
devices. First, if the data were already on the device (or the array is
implicit), a second copy of the data would be made. Second, the copy to
the device is likely less efficient. Third (and worst of all), the data
did not always get pulled back to the original array correctly.
This commit also contains instantiations of ArrayHandleVirtual and its
components for the most common types.
If an ArrayHandleVirtual is constructed without an underlying concrete
array handle, then the Storage<T, StorageTagVirtual> holds a
StorageVirtual pointer that is null. Generally, a null
ArrayHandleVirtual cannot do much, but its operations should still be
correct. There were a few places where the Storage would blindly try to
use its StorageVirtual pointer without checking it first. This adds some
conditions that should correct the behavior when StorageVirtual is null.
Previously, ArrayHandleVirtual was defined as a specialization of
ArrayHandle with the virtual storage tag. This was because the storage
object was polymorphic and needed to be handled special. These changes
moved the existing storage definition to an internal class, and then
managed the pointer to that implementation class in a Storage object
that can be managed like any other storage object.
Also moved the implementation of StorageAny into the implementation of
the internal storage object.