[petsc-dev] Using multiple mallocs with PETSc

[Richard Mills]

On Mon, Mar 13, 2017 at 11:21 AM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Sun, 12 Mar 2017, Karl Rupp wrote:
>
> >
> > > > If, however, the long-term goal is to get rid of global state, then
> we
> > > > would have to store a matching deallocation routine with the raw
> buffer.
> > > > Actually, you could store the function pointers to
> malloc/realloc/free in
> > > > the first bytes of the allocated buffer instead of an index.
> > >
> > >     That was my original thought but this is more likely to cause a
> random
> > >     crash if that space is corrupted; by using integers one can detect
> the
> > >     corruption before the crash occurs (in 99.9+ % of the cases of
> > >     corruption)
> >
> > that's a valid point, yes.
>
> How about:
>
> stash the metadata for each allocation (and pointers for corresponding
> free) in a hash table for all mallocs that we need to track? [this
> avoids the wasted 'space' in each alloc.]
>

I had considered proposing the same thing, but I wasn't sure about doing
this for all of the allocations (I have no idea right now, what, if any,
performance implications there might be most PETSc codes).  However, I
believe that previously in this thread, Barry floated the idea of having
something like PetscMallocNumeric() that we use for allocating the arrays
that hold vectors, matrices, etc., since these tend to be the large and
memory bandwidth-sensitive things.  Maybe use a hash table approach for
those to facilitate different types of allocators, but we have some
default, normal malloc() for other things?

--Richard


> Assuming valgrind works with special memory types - rely in it instead
> of the extra integer padding?
>
> Satish
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170313/2450a777/attachment.html>