[J3] [EXTERNAL] Re: Custom Memory Allocator

Reuben D. Budiardja reubendb at ornl.gov
Tue Nov 19 14:32:07 EST 2019

Hi Bill,

Well, my use of 'GPU memory' is only an example, so although it may be 
true that it may be obsolete in the future, it seems that there will 
always be some sort of memory hierarchy in the system, and so there may 
be a need to be able to allocate / deallocate Fortran object where the 
memory space is obtained from a custom / third-party library.

Otherwise it will always be compiler dependent.

Whether this is something that should be part of the language standard 
or relegated to directive like OpenMP is arguable of couse.


On 11/16/19 11:16 AM, Bill Long via J3 wrote:
> To reinforce Steve/s comment, there are a lot of situations in which an object declared allocatable will be automatically deallocated.  Those deallocations will always be done with the native deallocation routine.
> There was a proposal, I believe from Reinhold, to provide an attribute that would specify a “class” of memory where the object is supposed to reside.  Something like that could he morphed into a facility to handle this case.
> The hazard here is that the idea of separate GPU memory might very well become obsolete in the future. We don’t want to put a lot of work into specifying a feature that will become obsolete.  In that vain, I think that Jon’s suggestion of using the OpenMP facilities is the best one offered so far.  In the future, OpenMP directives can easily be turned off, or the compiler directed to ignore certain directive clauses. (This happens a lot already.)
> Cheers,
> Bill
>> On Nov 15, 2019, at 6:45 PM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
>> On 11/15/2019 7:15 PM, Reuben D. Budiardja via J3 wrote:
>>> Hi Steve,
>>> On 11/15/2019 03:37 PM, Steve Lionel via J3 wrote:
>>>> No, there is no way to do this and if you try playing games with the descriptor you may be in for big trouble later when the Fortran run-time wants to deallocate the memory, as it isn't using the C descriptor for that.
>>> Well, presumably whatever custom allocator will also have a deallocator to deallocate, so it won't be using Fortran runtime. But yes, care must be taken so that it doesn't get to the point that the runtime needs to deallocate.
>>> But out of curiosity, I am not sure what you meant by "it isn't using C descriptor", would a Fortran runtime not also update the C descriptor consistently when it allocate / deallocate, and using the same information that's there (e.g. the base address)?
>> Yes, if the descriptor is passed back or returned to the Fortran code it will use it, but it will use its own deallocator.
>> Steve
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425

Reuben D. Budiardja, Ph.D.
reubendb at ornl.gov | (865) 576-9519
National Center for Computational Sciences
Oak Ridge National Laboratory

More information about the J3 mailing list