[petsc-dev] Adding support memkind allocators in PETSc

[Jed Brown]

Richard Mills <rtm at utk.edu> writes:
> I think it is possible to add the memkind support without breaking all of
> the interfaces used throughout PETSc for PetscMalloc(), etc.  I recently
> sat with Chris Cantalupo, the main memkind developer, and walked him
> through PETSc's allocation routines, and we came up with the following: The
> imalloc() function pointer could have an implementation something like
>
> PetcErrorCode PetscMemkindMalloc(size_t size, const char *func, const char
> *file, void **result)
>
> {
>
>     struct memkind *kind;
>
>     int err;
>
>
>
>     if (*result == NULL) {
>
>         kind = MEMKIND_DEFAULT;
>
>     }
>
>     else {
>
>         kind = (struct memkind *)(*result);

I'm at a loss for words to express how disgusting this is.

> This gives us (1) a method of passing the kind of memory without modifying
> the petsc allocation routine calling sequence, 

Nonsense, it just dodges the compiler's ability to tell you about the
memory errors that it creates at every place where PetscMalloc is
called!


What did Chris say when you asked him about making memkind "suck less"?
(Using shorthand to avoid retyping my previous long emails with
constructive suggestions.)

> and (2) support a fall back code path legacy applications which will
> not set the pointer to NULL.  Or am I missing something?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150427/677de692/attachment.sig>