my only concern with this solution is that the lookup via indices relies on
global state. Since PETSc relies on global state at a bunch of other places
(e.g. logging), this may not be a relevant concern.
The OS keeps a little global state around too :-( What's the harm in this little table
in "global state"?
well, global state is not bad per se - we just need to keep its
implications in mind.
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.
Best regards,
Karli
With 256/512-byte-alignment it may not matter in terms of memory footprint
whether you store a single integer or whether you store three function pointers.
Best regards,
Karli
On 03/10/2017 01:19 AM, Barry Smith wrote:
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.
