> On Mar 10, 2017, at 8:45 AM, Karl Rupp <[email protected]> wrote:
>
> Hey,
>
> 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"?
>
> 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)
> 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.
>>
>>
>>
>>
>>
>>
>
