New Issue: Futures directions for CPtr memory alloc/free routines

18017, "bradcray", "Futures directions for CPtr memory alloc/free routines", "2021-07-01T03:42:11Z"

Currently, the CPtr module defines these routines for allocating and freeing memory:

proc c_calloc(type eltType, size: integral): c_ptr(eltType) { ... }
proc c_malloc(type eltType, size: integral): c_ptr(eltType) { ... }
proc c_aligned_alloc(type eltType, alignment: integral, size: integral): c_ptr(eltType) {
proc c_free(data: c_void_ptr) { ... }

As noted in a discussion that came up at https://github.com/Cray/chapel-private/issues/1896#issuecomment-818078445, these could be considered a bit odd in that:

  • their naming takes the c_foo() pattern, yet their signatures do not match C's definition of foo() (e.g., C's routines don't take a type or return a typed pointer
  • they don't call down to the corresponding C routines, but our runtime's version of the routines (which is sometimes the C routines, but more often jemalloc)

Some alternatives that have been discussed include:

  • having them mimic the C routines more closely and call the C routines directly since that's what their names imply (vote :+1: for this option

  • removing the c_ prefix in order to avoid the implication that these are C routines (vote :heart: for this option)

  • removing the c_ prefix and working harder to make the routines Chapeltastic. For example, perhaps we could just have an alloc() routine that takes a defaulted bool indicating whether or not to zero the memory and a defaulted alignment to indicate the alignment, reducing three routines to one (and maybe getting aligned allocations by default?) (vote :tada: for this option)

  • same as previous but preserving the c_ prefix. Sure it's another case of c_foo() incorrectly implying that we're calling C's foo() but (a)Â since C doesn't have an alloc() (right?), it's unlikely to be overly confusing; (b)Â it returns a c_ptr() so is still pretty C-like (vote :rocket: for this option)

  • something else?