Using different mallocs for different objects/arrays in PETSc is very iffy 
because each free() has to match the malloc used for that memory. This is even 
true with just -malloc_debug in that certain initialization functions in PETSc 
need to use the raw malloc() because we cannot be sure if the 
(*PetscTrMalloc)() has been set yet and the raw free() that comes at 
PetscFinalize() time needs to be matched with it.

  Why not have PetscMalloc() ALWAYS allocate an extra 64 bit space at the 
beginning and put in an integer indicating the malloc family that has been used 
to get the space. PetscFree() would use this integer to determine the correct 
free() to use. A mechanism to register new malloc families could be easily 
done, for example 

    PetscMallocRegister(malloc,realloc,free,&basicmalloc);
    
PetscMallocRegister(PetscMallocDebug,PetscReallocDebug,PetscFreeDebug,&debugmalloc);
    PetscMallocRegister(PetscMallocHBW,PetscReallocHBW,PetscFreeHBW,&hbwmalloc);

    To change the malloc used you would do PetscMallocPush(debugmalloc);  
PetscMalloc(....); .... PetscMallocPop();  Note that you can register 
additional malloc families at any time (it doesn't have to be as soon as the 
program starts up).

   What is wrong with the model and why shouldn't we use it?

  Barry

Notes: 

It is easy to implement, so that is not a reason. 

The extra memory usage is trivial.

The mapping from integer to malloc() or free() would be a bounds check and then 
accessing the function pointer from a little array so pretty cheap.

if certain mallocs are missing (like PetscMallocHBW) the hbwmalloc variable 
could be set to the basicmalloc value (or some other) so one would not need to 
ifdef if if () code deciding which malloc to use in many places.

It seems so simple something must be fundamentally flawed with it. Even with 
just PetscTrMallocDefault() and PetscMallocAlign() I feel like implementing it.




   

Reply via email to