-
David E. DeMarle authored
With this change a select few vtkObjects, including vtkBuffers, vtkDataArrays, and common vtkDataSets can optionally be constructed within in a potentially large memory space provided by Memkind. Memkind provides memory mapped buffers over any file system, but ideally one mounted -o dax and backed by fast non-volatile memory hardware like Optane. Applications set the specific location early on via vtkObjectBase::SetMemkindDirectoryi(). To try it, turn on the new VTK_USE_MEMKIND cmake configuration option and provide a path to link libmemkind. The option turns on the new and very experimental code paths. Memkind, and thus the option are only available under Linux. In user code, to create vtkObjects in the extended space call the ::ExtendedNew() function rather than the typical ::New() function. The TestMemkind test demonstrates and exercises the feature. The implementation is that ExtendedNew() turns on a static flag vtkObjectBase::UsingMemkind, that forces constructors to use memkind_malloc() instead of malloc(). The UsingMemkind flag is protected behind an RAII control, vtkObjectBase::vtkMemkindRAII() to make it safer to use correctly. All vtkObjects remember where they were created by virtue of an instance local vtkObjectBase::IsInMemkind flag. This is necessary to control behavior at runtime in a few instances but mostly to ensure that the correct free function, either memkind_free() or free(), is called when the object's lifetime ends. The temporal caching filter has been extended to optionally take advantage of the new capability. The new vtkTemporalDataSet::CacheIsInMemkind flag, tells the filter that it should create it's copies of the data it receives in the extended memory space. The flag is expected to be set before the cache is exercises and should remain unchanged for the duration of the program. The new TestTemporalCacheMemkind test exercises this capability.
9df08a7e